docs: sync from backend 6c01a30 — Gatus /api/health endpoint shipped
- Mark backend work as complete in Gatus Monitoring doc - Update follow-up issues table with status column - Add Activity Log entry for 2.6.49
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
# Gatus Monitoring — Proposed Config
|
||||
|
||||
**Status:** Draft / proposal. Not deployed yet.
|
||||
**Status:** Backend endpoint shipped in 2.6.49 (`backend@6c01a30`). Gatus config ready for deployment. Frontend `/api/health` proxy and ops deployment still pending.
|
||||
**Owner:** nick + claude
|
||||
**Author date:** 2026-05-28
|
||||
**Related:** [[Handoff - Request Network In-House Checkout - 2026-05-28]], memory entries `woodpecker_silent_build_fail` and `feedback-json-assets-copy-to-dist`.
|
||||
@@ -62,7 +62,7 @@ If RN's API goes down, in-house checkout still works (we already have the cached
|
||||
|
||||
## Required backend work (before Gatus can be useful)
|
||||
|
||||
The probe set above presumes a `GET /api/health` endpoint that exposes invariants without admin auth. It does NOT exist today.
|
||||
The `GET /api/health` endpoint was shipped in backend 2.6.49. It is public, rate-limited-skipped, and returns the structured check object below.
|
||||
|
||||
**Shape of the endpoint:**
|
||||
|
||||
@@ -89,7 +89,7 @@ Each `checks.*.ok` must reflect the actual current state, not a cached one. If a
|
||||
- The structure lets us add invariants later (e.g. `walletMonitor.ok`, `paymentRedisService.queueDepth`) without changing the URL.
|
||||
- Public exposure of counts (not addresses, not balances) is low-risk.
|
||||
|
||||
**Estimated work:** half a day backend, including a unit test that asserts every check's `ok` flag toggles correctly when the underlying dependency is mocked failed.
|
||||
**Backend work:** ✅ Complete (2.6.49). Includes `healthCheckService` with 5 checks, route wired in `app.ts`, rate-limiter + logging skip, and 5 route-level unit tests.
|
||||
|
||||
---
|
||||
|
||||
@@ -238,12 +238,12 @@ endpoints:
|
||||
|
||||
## Required follow-up issues
|
||||
|
||||
| # | What | Where |
|
||||
|---|------|-------|
|
||||
| 1 | Backend: add `GET /api/health` endpoint exposing the structured check object | `backend` (escrow-backend) |
|
||||
| 2 | Frontend: add `/api/health` Next.js route that fetches backend health and surfaces it (optional, for end-to-end check) | `frontend` (escrow-frontend) |
|
||||
| 3 | Ops: deploy Gatus config to the homelab Gatus instance, wire to Telegram | wherever the existing Gatus lives |
|
||||
| 4 | Ops: document the runbook for each alert (what to check when "backend-dev-health" fires) | this doc, or a sibling runbook file |
|
||||
| # | What | Where | Status |
|
||||
|---|------|-------|--------|
|
||||
| 1 | Backend: add `GET /api/health` endpoint exposing the structured check object | `backend` (escrow-backend) | ✅ Shipped in 2.6.49 |
|
||||
| 2 | Frontend: add `/api/health` Next.js route that fetches backend health and surfaces it (optional, for end-to-end check) | `frontend` (escrow-frontend) | ⏳ Pending |
|
||||
| 3 | Ops: deploy Gatus config to the homelab Gatus instance, wire to Telegram | wherever the existing Gatus lives | ⏳ Pending |
|
||||
| 4 | Ops: document the runbook for each alert (what to check when "backend-dev-health" fires) | this doc, or a sibling runbook file | ⏳ Pending |
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user