Uptime checks¶

Uptime checks let SLAtus detect outages automatically. A component with checks enabled is polled over HTTP, and the result can set its status without anyone clicking.

Configuration¶

Configured per component in the admin UI, under Services → (service), in the Uptime check card. Roles: admin and service_manager.

Setting	Column	Meaning
Enabled	`check_enabled`	Turns the checker on for this component
URL	`check_url`	Target of an HTTP GET request
Check interval (seconds)	`check_interval_seconds`	Time between two checks, 30 to 86,400 seconds, default 60
Failure threshold	`check_failure_threshold`	Number of consecutive failures before an outage is set
Result evaluation	`check_result_type`	`status_200`: success means a 2xx response. `body_contains`: the response body must contain `check_search_string`, regardless of status. If the search string is empty, the 2xx rule applies.
Outage severity	`check_outage_severity`	`major_outage` (default) or `partial_outage`
Degraded response time limit (ms)	`check_degraded_threshold_ms`	If set (default: off), a successful but slower response sets `degraded_performance`

A Test now button runs one check immediately. It is a diagnostic tool and does not change the check state or the history.

Pausing¶

Pause stops the check for a fixed time, in the UI 15 minutes, 1 hour, 4 hours or 24 hours (at most 7 days on the server, check_paused_until). The card then shows "Paused until …". Resume now ends the pause immediately. The sweep skips paused components.

How a sweep works¶

Every minute, the uptime-check-sweep job (lib/notifications/uptime-check.ts) runs. It checks every enabled, unpaused component whose interval has passed since its last check:

An HTTP GET with a 10-second timeout is performed. The response time is always measured.
The result is stored in uptime_check_results with the response time.
The component's cache fields last_checked_at, last_check_status and last_check_response_time_ms are updated.
Failure: consecutive failures are counted. When the threshold is reached, the sweep sets the configured outage severity through applyComponentStatusChange. The regular notification is sent. This also applies when the component was manually set to a different status, for example "Under maintenance"; if the manual status already matches the severity, it stays unchanged. The same applies to a manually raised outage severity: if the check keeps failing, the sweep sets the configured severity once more (and remains stable afterwards). Recovery and degradation, by contrast, do not touch a manually changed status. If the checker previously set degraded_performance itself, it escalates to the outage this way. The sweep records in check_set_status which status it last set.
Success: if the current status was set by the checker itself (outage or degradation) and the response is fast enough, the sweep sets operational. If the response is slower than the degraded threshold, it sets degraded_performance, but only if the component is operational or the checker set the outage itself. A manually set status remains unchanged.

Protection against overwriting manual changes¶

The sweep records in check_set_status which status it last set. The checker recovers a component only and downgrades it to degraded_performance only if it set the status itself or the component is operational — that is, the current status must still match the stored value exactly, even if the outage severity has since been changed. If a person changes the status, the checker's authority ends and check_set_status is reset on the next check. A severity that was set manually stays until a person changes it. An outage is the exception: when the failures reach the threshold, the sweep sets the configured outage severity.

History and display¶

Services → (service) → View history (/admin/services/[id]/uptime-history) lists the last 50 check results with time, result and error message.
Under Service Status, a colored icon per service shows the result and response time of the last check.

Retention¶

Results are kept for 30 days. The job uptime-check-retention deletes older rows every day at 03:00.

Operational notes¶

The checker requires the worker process. Without it, no checks run.
Checks run from the server where the worker runs. A URL that is only reachable from outside your network needs a worker there, or a check through an external monitor that calls the Public API.
Automatic checks and manual updates can both affect the same component. The status-change entry point serializes them, and the last change wins.