Deploy Gatus monitoring + add /api/health endpoint #1
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: nick/nick-doc#1
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
See doc at 08 - Operations/Gatus Monitoring - Proposed Config.md (commit
8a9e562).Full proposal lives in commit
8a9e562— see the doc for the Gatus YAML, the /api/health endpoint shape, and the retrospective table.Sub-tasks: (1) Backend: add public GET /api/health returning { status, version, checks: { db, redis, rnChainRegistry, rnTokenRegistry, rnApi } }. (2) Frontend (optional): proxy /api/health Next.js route. (3) Ops: deploy Gatus YAML from doc. (4) Ops: write alert runbook.
Acceptance criteria: (1) GET /api/health returns 200 with structured object when healthy. (2) Killing Mongo or breaking chain registry flips status to degraded/down within 30s. (3) Gatus dashboard renders all probes green when healthy. (4) Manually emptying supportedChains.json triggers Telegram alert within ~90s.
Status update 2026-05-29: backend GET /api/health endpoint shipped at backend@6c01a30 (2.6.49), wired public (no auth, no rate-limit). Gatus config deployed (escrow + escrow-external groups added with backend-health, RN-API, Chainalysis, BSC-RPC probes). One gate left: dev.amn.gg still serving 2.6.48 — once the 2.6.49 image build/push/deploy lands, the backend-health probe goes green and the chain-registry assertion (chainCount >= 1) protects against future empty-registry regressions.
Updated checklist: (1) Backend /api/health endpoint — DONE (2.6.49, 6c01a30). (2) Backend deployed to dev — PENDING (currently 2.6.48). (3) Gatus config deployed for dev — DONE (config.yaml lines 459-521). (4) Prod probes (amn.gg) — NOT YET, add after dev verifies. (5) Frontend Next.js /api/health proxy — OPTIONAL, skipping unless end-to-end check needed. (6) Runbook — NOT YET, write after first real alert fires so the runbook reflects actual response steps.