Monitoring HedgeDoc with Vigilmon: Status Endpoint, Web Editor, API Liveness & SSL Alerts

HedgeDoc is a self-hosted open-source real-time collaborative markdown editor that teams use to co-author documents, meeting notes, runbooks, and technical specs directly in the browser — with live multi-cursor editing and instant publishing to shareable URLs. When HedgeDoc goes down, active collaborative sessions disconnect mid-document, saved notes become inaccessible, and any shared links that external stakeholders are using return errors. HedgeDoc stores all notes and user accounts in a relational database (PostgreSQL or MySQL), so a database connectivity failure renders the entire platform non-functional even if the Node.js process is still running. Vigilmon gives you external visibility into HedgeDoc's status endpoint, web editor, API liveness, and SSL certificate so failures are caught within 60 seconds.

What You'll Build

• A monitor on HedgeDoc's /status health endpoint
• An HTTP monitor for the HedgeDoc web editor
• An HTTP monitor for the API liveness check (/api/private/me returning 401 confirms the API is alive)
• SSL certificate monitoring for your HedgeDoc domain
• An alerting setup tuned for collaborative document availability

Prerequisites

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

Step 1: Verify HedgeDoc's Status Endpoint

HedgeDoc exposes a lightweight health check at /status that returns the platform's operational state:

curl -i https://hedgedoc.example.com/status

A healthy instance returns HTTP 200 with a JSON body:

{"status":"up"}

This endpoint requires no authentication and is designed for uptime probes. A 200 response with "status":"up" confirms that the HedgeDoc Node.js server is running and its backing database is reachable. A non-200 response, a timeout, or a body without the "up" status indicates the server process has crashed, the database is unreachable, or a required service dependency has failed.

Database dependency: HedgeDoc stores every note, revision, user account, session token, and permission in its primary database (PostgreSQL or MySQL depending on your deployment). If the database becomes unreachable, HedgeDoc cannot serve any existing notes, create new notes, authenticate users, or persist collaborative edits — the entire platform is effectively down even if the Node.js process is still running. The /status endpoint checks this database connectivity and is your primary indicator of platform health.

Step 2: Create a Vigilmon HTTP Monitor for the Status Endpoint

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

This monitor catches:

• HedgeDoc Node.js server crashes or OOM kills from processing many simultaneous collaborative sessions
• Database connectivity failures — PostgreSQL or MySQL outages that prevent notes from loading or being saved
• Redis session store failures (if configured) that forcibly log out all active collaborators
• Container restart loops triggered by misconfigured environment variables (CMD_DB_URL, CMD_DOMAIN, CMD_SESSION_SECRET)
• Failed database migrations after a HedgeDoc version upgrade that prevent the server from starting

The up keyword check ensures HedgeDoc is reporting a healthy status body — not just a 200 from a reverse proxy fronting a crashed backend.

Collaborative session disruption: Unlike a simple content site, HedgeDoc maintains WebSocket connections for each active editing session. When the server crashes and restarts, all active collaborative sessions are disconnected and unsaved edits (held in memory awaiting a debounced database write) may be lost. Fast detection via the /status monitor minimizes the window in which active collaborators are working on data that cannot be persisted.

Step 3: Monitor the HedgeDoc Web Editor

The HedgeDoc web editor is the primary interface used to create, view, and collaboratively edit markdown documents. Monitor it independently from the API to catch reverse proxy failures and static asset serving problems:

1. Add Monitor → HTTP.
2. URL: https://hedgedoc.example.com.
3. Check interval: 60 seconds.
4. Expected status: 200.
5. Keyword: HedgeDoc.
6. Label: HedgeDoc Web Editor.
7. Click Save.

This monitor catches nginx or reverse proxy failures, CDN misconfiguration, and frontend asset serving errors that prevent users from opening the editor — even when the backend API is responding. A broken editor means no new notes can be created, no existing notes can be opened, and active collaborators cannot rejoin their sessions after a page refresh.

Step 4: Monitor API Liveness via the Private Me Endpoint

HedgeDoc's private API is used by the frontend for authentication, note management, and profile operations. Calling /api/private/me without a valid session returns 401 Unauthorized — the correct response confirming the API is alive and enforcing authentication:

curl -i https://hedgedoc.example.com/api/private/me
# Expected: HTTP 401 (API is alive, authentication is enforced)

1. Add Monitor → HTTP.
2. URL: https://hedgedoc.example.com/api/private/me.
3. Check interval: 60 seconds.
4. Expected status: 401.
5. Label: HedgeDoc API.
6. Click Save.

A 401 is the correct liveness signal: it proves the API server accepted the connection, ran the authentication middleware, and returned a proper HTTP response — meaning the HedgeDoc API layer is routing and processing requests correctly. A 502 or 504 means the reverse proxy is running but the HedgeDoc Node.js process is not responding. A 500 may indicate a database query failure on the authentication path.

Why 401 and not 200? HedgeDoc's private API routes require a valid session cookie. An unauthenticated request to /api/private/me is expected to return 401 — this is not an error, it is the correct security behaviour. Vigilmon monitoring for 401 means: if HedgeDoc ever returns 200 here (which would indicate a session bypass vulnerability) or anything other than 401 (which indicates an infrastructure failure), you get alerted. It is both a liveness check and a lightweight security sanity check.

Step 5: Monitor SSL Certificates

An expired SSL certificate on your HedgeDoc instance has immediate and severe consequences for collaborative workflows:

• All users are locked out simultaneously with TLS errors in their browsers
• Any external links shared in other tools (Slack, Jira, email) to HedgeDoc notes return certificate errors
• WebSocket connections for real-time collaboration fail — active sessions cannot be established
• Any CI/CD pipelines or scripts that programmatically create or update HedgeDoc notes via the API fail with TLS errors

1. Add Monitor → SSL Certificate.
2. Domain: hedgedoc.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 | |---|---|---| | /status | Non-200 or up missing | Check HedgeDoc container; inspect database connectivity; review Node.js server logs | | Web Editor | Non-200 or keyword missing | Check nginx/reverse proxy; verify static assets served; inspect container logs | | API /api/private/me | Non-401 response | Check HedgeDoc Node.js process; inspect API routing; verify database is reachable | | SSL certificate | < 30 days to expiry | Renew certificate; verify Let's Encrypt auto-renewal is functioning |

Alert after: 2 consecutive failures for HTTP monitors. Collaborative editing tools with active user sessions warrant fast escalation — a single confirmed failure during business hours should page whoever owns the deployment.

Notification routing: If your team uses HedgeDoc for runbooks and incident documentation, a HedgeDoc outage during an ongoing incident is doubly damaging — engineers cannot access the runbooks needed to resolve the incident they are trying to fix. Route HedgeDoc alerts to your primary on-call channel with high priority.

Common HedgeDoc Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | HedgeDoc Node.js server crash | Status endpoint unreachable; alert within 60 s | | Database (PostgreSQL/MySQL) down | Status endpoint returns non-200 or missing up; all notes inaccessible | | Database disk full | Status endpoint may fail; writes fail silently; edits are lost | | Redis session store failure | Users logged out mid-session; authentication fails | | Container restart loop | Status endpoint intermittently unavailable; flapping alerts | | Reverse proxy misconfiguration | Web editor monitor fires; API may still be partially reachable | | Static asset serving failure after upgrade | Web editor keyword check fails; blank page on load | | WebSocket proxy not configured | Real-time collaboration fails; single-user editing may still work | | SSL certificate expires | All monitors fire; TLS errors block all access | | DNS misconfiguration | All monitors fire simultaneously | | Database migration failure after upgrade | Server fails to start; status endpoint unreachable | | Memory exhaustion from large note rendering | Node.js OOM kill; status endpoint unreachable until container restarts |

Collaborative documentation tools are only useful when they are always available — a HedgeDoc outage during a sprint planning session or an active incident means lost context, missed decisions, and frustrated teams. Vigilmon watches HedgeDoc's status endpoint, web editor, API liveness, and SSL certificate so you're alerted within 60 seconds of any failure, before your team notices their collaborative notes are gone.

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