Monitoring EdgeDB with Vigilmon: HTTP API Health, Authentication, SSL Certificates & Query Engine Uptime Checks

EdgeDB is a graph-relational database that combines the modeling power of a graph database with the query composability of SQL — built on top of PostgreSQL and used in production by teams who want strong type safety, declarative schema migrations, and a modern query language (EdgeQL) without sacrificing relational integrity. Running EdgeDB in production means operating the EdgeDB server process, the underlying PostgreSQL backend, and the HTTP API layer that developer tooling and applications connect to. Any of these can fail independently: the EdgeDB process can crash, PostgreSQL can become unreachable, the auth layer can break after a config change, and TLS certificates can expire silently. Vigilmon gives you an external, independent monitoring layer for EdgeDB: server health, HTTP API availability, authentication checks, and SSL certificate expiry.

What You'll Build

• A health endpoint monitor confirming the EdgeDB server process is running
• An HTTP API availability check verifying EdgeDB is accepting connections
• An authenticated query smoke test confirming the query engine and auth layer are functional
• SSL certificate monitoring for your EdgeDB endpoint
• Alerting configured appropriate for a production database system

Prerequisites

• EdgeDB (v4.x or v5.x) running in server mode, accessible via HTTPS
• An EdgeDB instance name and credentials for a read-only monitoring role
• A free account at vigilmon.online

Step 1: Monitor the EdgeDB Server Health Endpoint

EdgeDB exposes a /server/status/alive endpoint that returns a fast liveness check without requiring authentication. This is the primary signal that the EdgeDB process is running and accepting TCP connections:

curl -I https://your-edgedb.example.com/server/status/alive

A healthy EdgeDB server returns 200 OK. A process crash, OOM kill, or startup failure will cause this check to fail before your application receives a connection error. Add the monitor:

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://your-edgedb.example.com/server/status/alive.
3. Check interval: 60 seconds.
4. Expected status: 200.
5. Label: EdgeDB - Liveness Check.
6. Click Save.

Default port: EdgeDB listens on port 5656 by default. In production, place EdgeDB behind a TLS-terminating reverse proxy (Nginx, Caddy) at port 443. If using the default port directly, your URL is https://your-host:5656/server/status/alive.

Step 2: Monitor the EdgeDB Server Ready Endpoint

The liveness endpoint confirms the process is running. The readiness endpoint confirms the EdgeDB server has completed startup and is ready to accept queries — these are distinct states during startup and after failover:

curl -I https://your-edgedb.example.com/server/status/ready

A healthy response returns 200 OK. During startup or after a crash recovery where PostgreSQL is reconnecting, the ready endpoint returns 503 while liveness returns 200. Add the monitor:

1. Add Monitor → HTTP.
2. URL: https://your-edgedb.example.com/server/status/ready.
3. Check interval: 60 seconds.
4. Expected status: 200.
5. Label: EdgeDB - Readiness Check.
6. Click Save.

Why both liveness and readiness: The liveness check catches hard crashes. The readiness check catches the subtler scenario where EdgeDB is alive but not yet serving — for example, waiting for its PostgreSQL backend to finish recovery after a failover or restart.

Step 3: Add an Authenticated Query Smoke Test via the HTTP API

EdgeDB's HTTP query API accepts EdgeQL queries with proper authentication. An authenticated smoke test confirms the full stack: EdgeDB process, PostgreSQL backend connectivity, and the auth layer:

First, generate an EdgeDB secret key for the monitoring role. In the EdgeDB CLI:

edgedb query --instance your-instance-name \
  "SELECT sys::get_version_as_str();"

Then probe the HTTP API with authentication:

curl -X POST https://your-edgedb.example.com/db/your-database/edgeql \
  -H "Authorization: Bearer your-secret-key" \
  -H "Content-Type: application/json" \
  -d '{"query": "SELECT sys::get_version_as_str();"}'

A healthy response returns the EdgeDB version string in a JSON envelope:

{"data": ["5.0-beta.2+..."]}

Add the monitor:

1. Add Monitor → HTTP.
2. URL: https://your-edgedb.example.com/db/your-database/edgeql.
3. Method: POST.
4. Request headers:
   • Authorization: Bearer your-secret-key
   • Content-Type: application/json
5. Request body: {"query": "SELECT sys::get_version_as_str();"}
6. Check interval: 5 minutes.
7. Expected status: 200.
8. Keyword: data.
9. Label: EdgeDB - Query Smoke Test.
10. Click Save.

What this catches: If EdgeDB loses its connection to the PostgreSQL backend, this query fails with a backend error while the health and readiness endpoints may still return 200. The smoke test is the earliest external signal for PostgreSQL backend failures — one of the most common EdgeDB failure modes.

Step 4: Monitor SSL Certificates

EdgeDB in production should be served over TLS. Certificate expiry breaks all client connections — application code, the EdgeDB CLI, and the EdgeDB UI all fail simultaneously:

curl -v https://your-edgedb.example.com/server/status/alive 2>&1 | grep -i "expire"

Add SSL monitoring:

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

EdgeDB's built-in TLS: EdgeDB can generate its own self-signed certificates for local development. For production, always use a proper CA-signed certificate. If you use EdgeDB Cloud or a managed deployment, the SSL monitor verifies the managed certificate is renewing correctly on your domain.

Step 5: Monitor the EdgeDB UI (If Enabled)

EdgeDB ships with a built-in web-based query editor and schema explorer at /ui. If you have the EdgeDB UI enabled in production for developer access, add a frontend availability check:

curl -I https://your-edgedb.example.com/ui

Add the monitor:

1. Add Monitor → HTTP.
2. URL: https://your-edgedb.example.com/ui.
3. Check interval: 5 minutes.
4. Expected status: 200.
5. Label: EdgeDB - UI Frontend.
6. Click Save.

This monitor is optional — the EdgeDB UI is typically not on the critical path for application availability. Add it if your team uses the UI for schema debugging or development workflows.

Step 6: Configure Alerting

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

| Monitor | Trigger | Action | |---|---|---| | EdgeDB - Liveness Check | Non-200 or timeout | EdgeDB process crashed; check systemd/Docker service and OOM logs | | EdgeDB - Readiness Check | Non-200 or timeout | EdgeDB starting up or PostgreSQL backend reconnecting; check backend connectivity | | EdgeDB - Query Smoke Test | Non-200 or data keyword missing | Query engine or PostgreSQL backend failure; check PostgreSQL status and EdgeDB logs | | EdgeDB - UI Frontend | Non-200 | UI static serving broken; lower priority, check EdgeDB server logs | | SSL Certificate | < 30 days to expiry | Renew certificate; check auto-renewal if using Let's Encrypt |

Alert sensitivity: Alert on the liveness and readiness checks after 1 consecutive failure — these are fast checks and a single failure is already abnormal. For the query smoke test, alert after 2 consecutive failures to avoid paging on transient query latency during heavy load.

Escalation: Route EdgeDB liveness and query smoke test alerts to your on-call channel. Database failures propagate immediately to application errors, and the readiness endpoint should alert your platform team to check for PostgreSQL issues.

Common EdgeDB Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | EdgeDB process OOM-killed | Liveness Check fires | | PostgreSQL backend unreachable or crashed | Readiness and Query Smoke Test fire; Liveness may stay green | | PostgreSQL running but in recovery (read-only) | Query Smoke Test fires on write queries | | EdgeDB auth configuration change breaking secrets | Query Smoke Test fires with auth error | | TLS certificate expires | SSL monitor alerts at 30-day threshold | | Schema migration failure during deployment | Query Smoke Test may fire if migration left schema inconsistent | | Disk full on EdgeDB host | PostgreSQL write failures; Query Smoke Test fires | | EdgeDB process started but not yet ready (slow startup) | Readiness fires; Liveness stays green | | Network partition to PostgreSQL backend | Query Smoke Test fires | | Reverse proxy misconfiguration after config change | All HTTP monitors fire |

Why Monitor EdgeDB with an External Tool

EdgeDB's internal health endpoints and PostgreSQL's own monitoring are inside your infrastructure perimeter — they go silent or become inaccessible in the scenarios that most need external visibility: network partitions, host failures, or misconfigured firewalls. Vigilmon provides the external watchdog: a check that runs from outside your environment and delivers alerts through a separate channel regardless of whether EdgeDB itself is reachable.

EdgeDB's layered architecture — EdgeDB process on top of PostgreSQL — means failures can occur in either layer with distinct symptoms. The three-layer monitoring strategy in this guide (liveness → readiness → authenticated query) surfaces failures at each layer independently, giving your team precise signals for faster diagnosis.

EdgeDB brings modern database ergonomics to production environments, but no database is immune to process crashes, backend connectivity failures, or certificate expiry. Vigilmon provides the independent external monitoring layer for EdgeDB: process health, server readiness, query engine smoke tests, and SSL certificate expiry — all checked from outside your network.

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