feat(ops): Build a /status health dashboard page showing live system component health, event throughput, and translation success rate

[grantfox-oss]

Body:
Summary
Open-Audit already exposes Prometheus metrics at /metrics and has a circuit breaker and rate limiter in lib/resilience/. However, there is no human-readable status page that shows the health of the system at a glance — not just for operators, but for any contributor or user who wants to understand whether the system is working correctly. This issue adds a public /status page and the backend API that powers it.
Required work
New API route: app/api/status/route.ts
Return a structured JSON health report:
json{
"status": "healthy" | "degraded" | "down",
"timestamp": "ISO8601",
"components": {
"stellarRpc": {
"status": "healthy" | "degraded" | "down",
"latencyMs": 142,
"lastChecked": "ISO8601",
"circuitBreakerState": "closed" | "open" | "half-open"
},
"database": {
"status": "healthy" | "down",
"latencyMs": 8,
"lastChecked": "ISO8601"
},
"redis": {
"status": "healthy" | "down" | "not-configured",
"latencyMs": 2,
"lastChecked": "ISO8601"
},
"worker": {
"status": "healthy" | "down" | "not-configured",
"lastHeartbeat": "ISO8601"
}
},
"metrics": {
"eventsIndexedLast1h": 1452,
"eventsIndexedLast24h": 18934,
"translationSuccessRate1h": 0.94,
"translationSuccessRate24h": 0.97,
"averageTranslationLatencyMs": 12,
"activeWebSocketConnections": 7
}
}
Implementation:

Stellar RPC health: ping getLatestLedger and record latency; read circuit breaker state from lib/resilience/circuit-breaker.ts
Database health: run SELECT 1 via Prisma and record latency
Redis health: ping Redis if REDIS_URL is set; return "not-configured" otherwise
Worker health: the indexer worker writes a heartbeat key to Redis every 30 seconds; the status API reads it and marks the worker "down" if the key is older than 90 seconds
Metrics: query the database for event counts and translation outcomes in the last 1h and 24h windows
Overall status is "healthy" if all configured components are healthy; "degraded" if any component is degraded but the system is partially functional; "down" if Stellar RPC or the database is unreachable

New page: app/status/page.tsx

Server-rendered page that fetches /api/status on load and refreshes every 30 seconds (use setInterval + router.refresh())
Display each component as a status row with a green/amber/red indicator dot, component name, latency, and last-checked time
Display the metrics section as a simple stats grid (events per hour, translation success rate, active connections)
Show a banner at the top: "All systems operational" (green), "Partial outage" (amber), or "Major outage" (red)
The page must render meaningfully even when the API is partially down — show what is available and grey out what is not

Worker heartbeat:

Add a setInterval in src/worker/indexer.ts that writes HSET open-audit:worker:heartbeat lastSeen to Redis every 30 seconds

Acceptance criteria

GET /api/status returns a valid JSON response in under 500ms under normal conditions
Each component's health reflects its actual state — simulate a Stellar RPC timeout and confirm stellarRpc.status becomes "down" and overall status becomes "degraded"
The /status page renders correctly in a browser with all component rows and metric stats visible
The page auto-refreshes every 30 seconds without a full page reload
Worker heartbeat is written to Redis correctly and the status API correctly detects a stale heartbeat as "down"
Unit tests cover: all-healthy response shape, degraded when one component fails, down when database is unreachable, stale worker heartbeat detection
npm run lint and npm test pass with no regressions

[clintjeff2]

Hello, I have 6 years of experience working on tasks like this and handling similar challenges across backend, frontend, and smart-contract development. I have carefully read and fully understood the task requirements, and I am confident I can deliver a clean, efficient, and well-tested solution promptly. I always ensure high-quality implementation, maintainability, and adherence to best practices.

Pull request in 5 hours.

[Opeyemi01-del]

Hi maintainers 👋

I'd like to take on feat(ops): Build a /status health dashboard page showing live system component health, event throughput, and translation success rate.

Why I'm a good fit:

• Intermediate experience with UI development, including data-driven dashboards and real-time displays
• Active open source contributor — I know how to read a codebase, match existing conventions, and deliver reviewable PRs
• The three core pieces here (component health indicators, event throughput metrics, and translation success rate) are well-scoped and something I'm confident tackling

My implementation plan:

1. Review existing patterns (routing, data fetching, component structure) before starting
2. Build the /status route and page shell
3. Implement each panel in sequence: system component health → event throughput → translation success rate
4. Add appropriate loading, error, and empty states throughout

I can have a draft PR up within [X days]. Happy to discuss the approach or share prior work before you assign. Thanks for keeping this project going! 🙏

[iammsb]

Over the past 7months I have taken full stack experience on most LLMs and I have contributed off github platform on other key major start up projects which I signed NDA with, but over time I have core experience when it comes to project development and implementation.

[temitop48]

I'd like to take on this issue.

I've worked extensively with Next.js, TypeScript, server-side APIs, dashboard interfaces, and backend integrations, and I've contributed to open source projects through GitHub. This issue aligns well with my experience building monitoring and data-driven applications.

My approach will be to first understand the existing architecture and reuse the current resilience, database, and service abstractions rather than introducing new patterns. I'll implement the /api/status endpoint, build the server-rendered /status page with automatic refresh, add the worker heartbeat mechanism, and ensure the health calculations accurately reflect component status under healthy, degraded, and failure scenarios. Finally, I'll add comprehensive unit tests and verify that npm run lint and npm test pass before submitting the PR.

I'll keep the implementation focused, well-tested, and consistent with the project's coding style.

[Ajuwonlo]

Thanks for opening this issue.

After going through the description, I have a good idea of the work involved and would be interested in taking it on. I've worked on similar problems before, particularly around investigating root causes, implementing maintainable fixes, and validating changes through thorough testing.

My plan would be to first understand the current behavior, identify the source of the issue, and then submit a well-tested PR with any necessary documentation updates.

If no one is currently assigned, I'd be happy to work on this and keep the discussion updated with my progress.

[abdullahilateefat03-boop]

Hello, I'm Lateefat. I've reviewed the issue requirements and would like to work on this task. My background in software development equips me to contribute effectively. Please assign it to me.

[Kappa16]

Please maintainer..I can handle this professionally and make sure this issue is closed ASAP WITHOUT ERRORS.

[tomiwasamuel087-arch]

To enhance good living

[modest12345678]

Hi team 👋

I'd like to apply for this issue.

Motivation

Observability gaps are silent killers in production — you don't know the system is degraded until a user reports it. A structured /status page solves exactly this: it gives operators, contributors, and users a single URL to assess system health at a glance, without needing to understand Prometheus or dig through logs. I've been following Open-Audit's architecture closely and this is one of the most impactful UX additions the project can ship.

What I'll build

I've already studied the codebase and have a clear plan:

GET /api/status — Runs four parallel health probes using Promise.allSettled (no cascading failures):

Stellar RPC: pings getLatestLedger() with a 5 s timeout and reads the CircuitBreaker state from lib/resilience/circuit-breaker.ts
Database: prisma.$queryRaw\SELECT 1`` with latency measurement
Redis: conditional client.ping() — returns "not-configured" when REDIS_URL is unset
Worker: reads HGET open-audit:worker:heartbeat lastSeen and marks "down" if stale > 90 s
Metrics: scoped COUNT queries on the Event model for 1 h / 24 h windows with status = "translated" for success rate
/status page — Server-rendered with SSR initial data; a "use client" StatusClient component handles 30 s auto-refresh via setInterval + router.refresh(). Displays a colour-coded banner, per-component status rows (dot + latency + last-checked), and a metrics grid. Degrades gracefully when components are unavailable.

Worker heartbeat — A setInterval added to src/worker/indexer.ts that writes HSET open-audit:worker:heartbeat lastSeen to Redis every 30 s, wrapped in try/catch so heartbeat failure never crashes the indexer.

Unit tests (Vitest) — Covers: all-healthy shape, RPC timeout → degraded, DB down → 503, stale heartbeat → down, Redis not-configured, response time < 500 ms.

Experience

I have hands-on experience with:

Next.js App Router (API routes, server/client component split, fetch with cache: "no-store")
Prisma + PostgreSQL (aggregate queries, raw queries, connection management)
Redis (ioredis, hset/hget, connection pooling, conditional checks)
Stellar SDK (RPC calls, event indexing patterns)
Vitest (mocking modules, timing assertions)
Health check / observability patterns (circuit breakers, heartbeat detection, structured JSON status APIs)
Timeline

I can deliver a complete PR — API, page, heartbeat, and tests — within 3–5 days of assignment, with npm run lint and npm test passing cleanly.

Happy to discuss any design decisions (e.g., circuit breaker singleton access, WebSocket connection counting) before I start. Looking forward to contributing! 🚀

[canicefavour]

I can implement this end-to-end system status feature, having built similar operational dashboards and health monitoring APIs before, by exposing a performant /api/status endpoint, a resilient auto-refreshing status page, Redis-backed worker heartbeats, and comprehensive health checks for Stellar RPC, the database, Redis, and application metrics with full test coverage for healthy, degraded, and failure scenarios.