Services
HTTP and TCP checks, health documents, status history and per-service rules.
A service is something that serves requests and can be up or down.
Adding one
Monitor → Services → Add service.
| Field | Notes |
|---|---|
| Name | What a stranger would call it at 3 a.m. |
| URL / host+port | HTTP(S) or TCP |
| Check interval | 60 s is a sensible default |
| Expected status | Default 2xx |
| Timeout | Shorter than the interval |
| Environment | See Environments |
| Team | Who gets paged |
Checks start immediately. The MONITOR_SYNC_INTERVAL setting (default 30 s)
controls how often the worker sweeps for due checks; a service's own interval
decides how often it is actually checked.
Below about 30 seconds you are mostly measuring your own checker rather than the service. If you need sub-30-second detection, a synthetic check or an in-process metric is a better instrument.
Health documents
If a service exposes a health document, AccelerUp reads it whole rather than reducing it to up/down.
Supported shapes are detected automatically — Spatie-style, Spring Actuator, and a generic form. A check added on the application side appears in AccelerUp with no change here; that is the entire reason for reading a document rather than writing a collector per dependency.
The application's own health document is the inside view of its dependencies, and for those it is the only accurate one: it holds the credentials, it knows which dependencies are essential, and it has already decided what healthy means for each.
The agent can read the same document from inside the network. The control plane can only reach a publicly routable one — which covers a public application and covers nothing else. Same document, same parser, different transport.
Status
| Status | Means |
|---|---|
| Up | The last check succeeded |
| Degraded | Responding, but slowly, or a non-essential dependency is unhealthy |
| Down | The last check failed |
| Unknown | No check has succeeded yet — not the same as up |
Rules
Each service carries its own rules: status, response time, and any value the health document reports.
Every rule uses the shared model — For, Recovery, Cooldown, severity, warn
level, routing. See How alerting works.
A service that stops responding does not resolve its open alerts. Absence is not evidence of recovery.
Use alert templates when the same rule should apply to many services, so the tenth one does not get a slightly different threshold from the first.
Check now
Check now runs the check immediately, out of schedule, and shows the raw result — status code, timing, body snippet, TLS details. It is the fastest way to tell a broken service from a broken check.
The service page
- Status and response-time history with the incident overlay
- Health document with each dependency's own state
- Rules and their current state
- Recent alerts
- Dependencies — see Dependency map
- Servers it runs on — see Servers
Multi-location checking
MONITOR_LOCATION labels each check with where it ran from. Run checkers in
several regions and the history says whether "down" meant everywhere or from one
place — which is a different incident.
Where this behaviour lives: backend/internal/worker/monitor_worker.go, backend/internal/service/service_svc.go. If the code and this page disagree, the code is right — please fix the page.
Part of Monitor — Everything that watches something and reports what it saw.