tutorial

Monitoring Wiki.js with Vigilmon: Web Availability, GraphQL API, Health Route & SSL Alerts

How to monitor Wiki.js self-hosted wiki platform with Vigilmon — web availability checks, GraphQL API liveness, health route monitoring, and SSL certificate alerts to keep your team's knowledge base online.

Wiki.js is the open-source wiki platform teams use to build internal knowledge bases, developer documentation, runbooks, and onboarding guides. Unlike a static site, Wiki.js is a live Node.js application backed by a database — it handles user authentication, page rendering, search indexing, and collaborative editing in real time. When Wiki.js goes down, your team loses access to the runbooks they need during incidents, the onboarding guides new hires depend on, and the documentation that answers questions before they become support tickets. Vigilmon gives you external visibility into Wiki.js's web availability, GraphQL API, health route, and SSL certificate so you're notified the moment your knowledge base becomes unreachable.

What You'll Build

  • An HTTP monitor for Wiki.js web availability
  • A liveness check on the GraphQL API endpoint (400 = alive)
  • A monitor on the /healthz health route
  • SSL certificate monitoring for your Wiki.js domain

Prerequisites

  • A running Wiki.js instance with a public or network-reachable domain
  • HTTPS configured via a reverse proxy (e.g., https://wiki.example.com)
  • A free account at vigilmon.online

Step 1: Verify Wiki.js Web Availability

Wiki.js serves its web interface from the root path. A successful response confirms the Node.js application is running and the reverse proxy is routing traffic correctly:

curl -I https://wiki.example.com
# Expected: HTTP/2 200

The root path returns the Wiki.js HTML shell or a redirect to the login page — either confirms the application is serving traffic. This is your primary availability signal.

Step 2: Create a Vigilmon HTTP Monitor for Web Availability

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://wiki.example.com.
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: Wiki.
  7. Label: Wiki.js Web Availability.
  8. Click Save.

This monitor catches:

  • Wiki.js Node.js process crashes or container restarts
  • Reverse proxy failures that prevent traffic from reaching the application
  • Database disconnection that causes Wiki.js to fail on startup
  • Configuration errors after upgrades that prevent the application from loading

When this monitor fires, your entire team loses access to the knowledge base — runbooks, incident response guides, onboarding materials, and API documentation become unavailable.

Step 3: Monitor the GraphQL API for Application Liveness

Wiki.js's API is built on GraphQL and served at /graphql. A GET request to this endpoint with no query returns HTTP 400 Bad Request with a JSON error body — this is the correct behavior for a GraphQL endpoint receiving a malformed request, and it confirms the application's API layer is alive and routing requests:

curl https://wiki.example.com/graphql
# Expected: HTTP 400 with JSON body

A typical response:

{"errors":[{"message":"Must provide query string."}]}
  1. Add Monitor → HTTP.
  2. URL: https://wiki.example.com/graphql.
  3. Check interval: 5 minutes.
  4. Expected status: 400.
  5. Keyword: errors.
  6. Label: Wiki.js GraphQL API.
  7. Click Save.

Why monitor a 400? An HTTP 400 from the GraphQL endpoint means the Node.js application received the request, parsed it, and responded with a structured error because no query was provided. A 502 Bad Gateway or connection timeout means the reverse proxy can't reach the application at all. The 400 is the liveness signal — it proves the entire request path from your network through the reverse proxy to the Node.js application is functioning.

Step 4: Monitor the Health Route

Wiki.js exposes a /healthz route that returns a simple status response. This endpoint is designed for health probes and load balancers:

curl https://wiki.example.com/healthz
# Expected: HTTP 200
  1. Add Monitor → HTTP.
  2. URL: https://wiki.example.com/healthz.
  3. Check interval: 60 seconds.
  4. Expected status: 200.
  5. Label: Wiki.js Health Route.
  6. Click Save.

Note: The /healthz route behavior may vary slightly by Wiki.js version. If your instance returns a 404 on this path, use the root path monitor from Step 2 as your primary health signal and skip this step, or check your Wiki.js version's documentation for the correct health route.

Monitoring /healthz separately from the web availability check gives you two independent signals. If the root path monitor fires but /healthz stays green, the failure is likely in the frontend rendering pipeline rather than the application server itself.

Step 5: Monitor SSL Certificates

Wiki.js is your team's knowledge base — the place engineers look when something breaks and managers look for process documentation. An expired SSL certificate:

  • Blocks all team members from accessing the wiki in a browser
  • Prevents CI/CD pipelines that read documentation from the API from connecting
  • Breaks any embedded documentation widgets that load from the Wiki.js API
  • Disrupts search integrations that index Wiki.js content
  1. Add Monitor → SSL Certificate.
  2. Domain: wiki.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

SSL certificate expiry is especially costly for an internal knowledge base — teams often discover it only during an incident, when they need the runbooks most.

Step 6: Configure Alerting

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

| Monitor | Trigger | Action | |---|---|---| | Web Availability | Non-200 or keyword missing | Check Wiki.js container; inspect Node.js process logs; verify reverse proxy | | GraphQL API | Non-400 response | Check application routing; if 502, backend container may be down | | /healthz | Non-200 response | Check application health; compare with web availability monitor | | SSL certificate | < 30 days to expiry | Renew certificate; verify ACME/Let's Encrypt auto-renewal is running |

Alert after: 2 consecutive failures for HTTP monitors. Wiki.js is typically stable — a second consecutive failure confirms a real outage rather than a transient glitch.

Common Wiki.js Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Node.js process crash | Web availability and GraphQL monitors fire; alert within 60 s | | Database connection failure | Application fails to start or degrades; web availability monitor fires | | Database migration failure after upgrade | Node.js exits with migration error; all monitors fire | | Reverse proxy misconfiguration | Web availability fires; application container may be healthy | | Static asset serving broken | Web dashboard renders partially; keyword check fails | | Elasticsearch/search index unavailable | Wiki functions but search fails; requires application-level logging to catch | | Out-of-memory kill | Node.js OOM-killed; all monitors fire simultaneously | | SSL certificate expires | SSL monitor alerts at 30 days; team loses wiki access at the worst possible time | | Storage backend unavailable | Page attachments fail; new page creation may error | | DNS misconfiguration | All monitors fire simultaneously |

Your internal knowledge base is most valuable exactly when your team is under pressure — during incidents, onboarding, and complex debugging sessions. Vigilmon watches Wiki.js's web availability, GraphQL API, health route, and SSL certificate so you're alerted within 60 seconds of any failure, with enough warning to restore access before your team reaches for the documentation and finds it gone.

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

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles