Overview
Monitor the operational status and uptime of the VeriWorkly ecosystem.
Description
The Health API exposes two deliberately different probes. Picking the right one matters: one is cheap enough to poll every 30 seconds, the other is not.
Use them for uptime monitoring services (UptimeRobot, BetterStack) and for automated deployment health checks in CI/CD pipelines.
Liveness vs. readiness
| Endpoint | What it checks | Cost | Failure mode |
|---|---|---|---|
GET /health | Only that the Node.js process is responding. | Free — touches no external dependency. | Never returns 503. |
GET /health/ready | PostgreSQL (SELECT 1) and Redis (PING). | Wakes database compute on every call. | Returns 503. |
Poll the liveness probe, not the readiness probe
GET /health intentionally performs no database or Redis check, so that frequent uptime
polling does not keep serverless database compute awake. It reports { status, timestamp } and
nothing else. Reserve GET /health/ready for deploy gates and manual diagnostics.
Authentication
| Method | Access Level | Requirement |
|---|---|---|
GET | Public | None. These are the only two endpoints on the API that need no key or session. |
Available Endpoints
GET /health— Liveness CheckGET /health/ready— Readiness Check
API Reference
Complete integration guide and OpenAPI specifications for the VeriWorkly backend.
Liveness CheckGET
Lightweight liveness probe. Confirms the API process is up and responding. It deliberately touches **no** external dependency — no database query, no Redis command — so that frequent uptime polling does not keep database compute awake. It therefore cannot report on PostgreSQL or Redis, and never returns `503`. For dependency health use `GET /api/v1/health/ready`. This is the only truly public endpoint on the API: it requires no session, no API key, and no first-party origin.