Monitoring BookStack with Vigilmon: Root Path, Login Page, API Docs Endpoint & SSL Alerts

BookStack is a self-hosted open-source knowledge base and documentation platform — a structured wiki built around a Books, Chapters, and Pages hierarchy that teams use to store technical documentation, onboarding guides, runbooks, and internal wikis. Engineering and operations teams choose BookStack because it combines the structure of a traditional wiki with a modern WYSIWYG editor, role-based access control, and a full REST API. When BookStack goes down, the entire team loses access to their shared knowledge simultaneously: engineers cannot access runbooks during an incident, support teams lose their process documentation, and onboarding employees cannot reach their training materials. BookStack runs on a LAMP/LEMP stack with MySQL or MariaDB as its primary database — a database failure makes the platform entirely non-functional. Vigilmon gives you external visibility into BookStack's root availability, login page, API docs endpoint, and SSL certificate so failures are caught within 60 seconds.

What You'll Build

• An HTTP monitor for BookStack's root path availability
• An HTTP monitor for the login page
• An HTTP monitor for the API docs endpoint (/api/docs returning 200 with JSON confirms the API is alive)
• SSL certificate monitoring for your BookStack domain
• An alerting setup tuned for knowledge base criticality

Prerequisites

• A running BookStack instance with a public or network-reachable domain
• HTTPS configured (e.g., https://bookstack.example.com)
• A free account at vigilmon.online

Step 1: Verify BookStack's Root Path

BookStack does not expose a dedicated /health endpoint, but the root path (/) is a reliable availability indicator. A GET request to the root redirects to the login page (if the user is not authenticated) or the homepage (if authenticated sessions exist). Either way, a 200 response on the root path confirms that the PHP application server is running, the web server (Apache or nginx) is serving requests, and the database connection is healthy enough for the session check:

curl -iL https://bookstack.example.com/

A healthy instance returns HTTP 200 after the redirect, with an HTML body containing the BookStack interface. A 500 error typically indicates a PHP error or database connectivity failure. A 502 or 504 means the web server is running but the PHP-FPM process is not responding.

MySQL/MariaDB dependency: Every book, chapter, page, attachment, user account, role, permission, and audit log entry is stored in MySQL or MariaDB. BookStack performs a database connection check on almost every request — a database failure causes immediate 500 errors across the entire platform. The root path availability check is therefore a direct proxy for database health. If the root returns 200, the database is reachable.

Step 2: Create a Vigilmon HTTP Monitor for the Root Path

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://bookstack.example.com.
3. Check interval: 60 seconds.
4. Response timeout: 15 seconds.
5. Expected status: 200.
6. Keyword: BookStack.
7. Label: BookStack Root.
8. Click Save.

This monitor catches:

• PHP-FPM process crashes or OOM kills
• MySQL/MariaDB connectivity failures — the database stores all content, users, and permissions; a database outage makes every page and book inaccessible
• Web server (Apache/nginx) failures that prevent PHP from being invoked
• Container or VM restarts that take BookStack offline temporarily
• PHP fatal errors from misconfigured .env settings (DB_HOST, DB_DATABASE, APP_KEY)
• Application storage permission errors that prevent session files from being written

The BookStack keyword check ensures the web server is returning the actual BookStack application and not a default Apache or nginx placeholder page.

Step 3: Monitor the Login Page

The login page is the primary entry point for all BookStack users. It is slightly deeper in the application stack than the root redirect — it renders a full Blade template, queries the database for authentication configuration (LDAP or local auth settings), and loads CSS and JS assets. Monitor it independently to catch application rendering failures that the root redirect might not surface:

1. Add Monitor → HTTP.
2. URL: https://bookstack.example.com/login.
3. Check interval: 60 seconds.
4. Expected status: 200.
5. Keyword: Login.
6. Label: BookStack Login Page.
7. Click Save.

This monitor catches login-specific failures such as session middleware errors, LDAP configuration failures that break the login page render, and template compilation errors after a BookStack upgrade. If users cannot reach the login page, they cannot access any content regardless of whether the underlying database and files are intact.

LDAP and SSO note: If your BookStack instance is configured with LDAP, Active Directory, or SAML authentication, a failure in the external identity provider causes the login page to return 500 or render with an error message. The login page keyword check will catch this: if the identity provider is down, the Login keyword will be absent from the error page that BookStack renders instead.

Step 4: Monitor the API Docs Endpoint

BookStack exposes a full REST API for programmatic access to books, chapters, pages, shelves, and attachments. The /api/docs endpoint returns a JSON document describing the API schema — it is served without authentication and returns HTTP 200 with a JSON body, confirming that the BookStack API subsystem is operational:

curl -i https://bookstack.example.com/api/docs
# Expected: HTTP 200 with JSON body describing the API

1. Add Monitor → HTTP.
2. URL: https://bookstack.example.com/api/docs.
3. Check interval: 60 seconds.
4. Expected status: 200.
5. Keyword: api.
6. Label: BookStack API Docs.
7. Click Save.

A 200 response with JSON confirms that the BookStack API layer is functional. A 404 may indicate an older BookStack version without API support, or that the API_REQUESTS_PER_MIN rate limit is misconfigured and the route is not registered. A 500 means a PHP error occurred in the API documentation generation.

API integrations at risk: If your team uses the BookStack API to sync documentation from CI/CD pipelines, to search and embed pages in other tools, or to automate content management, the API docs endpoint failure is an early warning that those integrations may be broken. Many teams automate documentation updates via the API on every code deployment — a broken API means stale docs that nobody flags until a human notices the content is months out of date.

Step 5: Monitor SSL Certificates

BookStack hosts your team's institutional knowledge. An expired SSL certificate:

• Locks every team member out of all documentation simultaneously with TLS errors
• Breaks any external integrations calling the BookStack REST API over HTTPS
• Prevents the BookStack app from loading assets from HTTPS paths (if APP_URL uses HTTPS)
• Causes any embedded BookStack page previews or iframes in other tools to fail

1. Add Monitor → SSL Certificate.
2. Domain: bookstack.example.com.
3. Alert when expiry is within: 30 days.
4. Alert again: 14 days, 7 days, 3 days, 1 day.
5. Click Save.

Step 6: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | Root path | Non-200 or BookStack missing | Check PHP-FPM and web server; inspect MySQL/MariaDB connectivity; review PHP error log | | Login page | Non-200 or Login missing | Check LDAP/SSO configuration; inspect session middleware; review Blade template errors | | API Docs | Non-200 or api missing | Check BookStack API configuration; inspect API_REQUESTS_PER_MIN setting; review routes | | SSL certificate | < 30 days to expiry | Renew certificate; verify Let's Encrypt auto-renewal is functioning |

Alert after: 2 consecutive failures for HTTP monitors. BookStack is a passive knowledge repository — a single 60-second outage is usually a container restart and self-recovers. Two consecutive failures indicate a real problem that requires intervention.

Escalation policy: If your BookStack instance hosts incident runbooks or on-call procedures, route alerts to your infrastructure on-call rotation. Losing access to runbooks during an active incident compounds the incident — engineers are flying blind precisely when they need documented procedures most.

Common BookStack Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | PHP-FPM crash or OOM kill | Root path returns 502/504; alert within 60 s | | MySQL/MariaDB down | Root path returns 500; all content inaccessible | | Database disk full | Writes fail; pages cannot be saved; may surface as 500 errors | | Web server (Apache/nginx) crash | Root path unreachable; all monitors fire | | Session storage failure | Login page may render but authentication fails | | LDAP/AD identity provider down | Login page keyword check fails; 500 rendered instead | | PHP fatal error after upgrade | Root path or login page returns 500 | | BookStack storage permission error | File uploads fail; may surface as PHP warnings on page renders | | Missing APP_KEY after migration | Entire application fails to boot; root returns 500 | | SSL certificate expires | SSL monitor alerts at 30 days; all users locked out | | DNS misconfiguration | All monitors fire simultaneously | | Composer autoloader missing after deployment | PHP fatal error; root path returns 500 | | Queue worker down | Notifications and background tasks fail silently; pages still load |

Knowledge bases are only valuable when they are accessible — a BookStack outage means every engineer, support agent, and new hire loses access to your team's shared institutional knowledge simultaneously. Vigilmon watches BookStack's root path, login page, API docs endpoint, and SSL certificate so you're alerted within 60 seconds of any failure, before your team starts filing Slack threads asking where the runbook went.

Start monitoring BookStack in under 5 minutes — register free at vigilmon.online.