System health
Is AccelerUp itself working — workers, integrations, and the last successful sync of each.
Settings → System Health monitors AccelerUp itself.
Why it exists
Monitoring that has quietly stopped working is worse than no monitoring, because everybody believes they are covered. This page is the check on the checker.
What is shown
| Workers | Each background worker, its last run and its state |
| Integrations | Each datasource and its last successful sync |
| Database | Connectivity, pool usage, migration state |
| Queues | Notification retry depth, pending work |
Last successful sync is the number to check
An integration whose credentials expired looks identical to one with nothing to report. Both show no new data. The only thing that distinguishes them is the timestamp of the last successful sync.
Check it after every credential rotation. This is the single most common cause of monitoring silently stopping.
Health endpoints
| Endpoint | |
|---|---|
/health | Liveness — the process is up |
/ready | Readiness — the database is reachable and migrations have run |
The load balancer should use /ready. A replica that is up but still migrating
is not ready to serve.
Workers and replicas
Workers are leader-gated: with two replicas, each worker runs on exactly one. A worker showing as running on one replica and not the other is correct.
Start-up log lines name each worker as it registers, which is the quickest way to confirm what a given replica is running.
Self-alerting
AccelerUp alerts on its own failures — a worker that has stopped, an integration that has not synced, a notification delivery that failed.
Delivery failures now name the event and the message, not just the channel, so the next one can be diagnosed from the alert.
Send AccelerUp's own system alerts to a different channel from your operational alerts, and ideally through a different transport. A platform that can only tell you it is broken through the thing that is broken cannot tell you it is broken.
Where this behaviour lives: frontend/src/app/settings/, backend/internal/handler/health_handler.go. If the code and this page disagree, the code is right — please fix the page.
Part of Administration — Settings, retention, platform thresholds and change tracking.