Uptime checks
How DomainCare's HTTP uptime probe works, what alerts it fires, and how to read latency stats.
Uptime checks
The uptime check sends an HTTP request to your domain every minute and records whether the server responded, how fast it responded, and what HTTP status code it returned. If any of those change in a meaningful way, DomainCare fires an alert.
What the probe does
On each check cycle, DomainCare sends a GET request to the root URL of your domain (e.g. https://example.com/). It measures:
- Reachability — did the server respond at all?
- Status code — what HTTP code did it return?
- Response time — how long did the full response take in milliseconds?
The probe records 3xx redirect responses directly without following them. A 301 or 302 is captured as-is — DomainCare does not chase the redirect chain on the uptime check (see /docs/checks/redirect for the dedicated redirect chain check). If no response arrives within the timeout window, DomainCare treats the request as a failure.
Alerts this check produces
| Event | Tone | When it fires |
|---|---|---|
website_down | Failure | Server did not respond, timed out, or returned a 5xx error. 4xx responses (e.g. 403 Forbidden) do not trigger this alert — the server is still reachable. |
website_back_online | Recovery | Server is reachable again after a website_down event |
website_slow_response | Warning | Response time exceeded the slow-response threshold |
http_status_code_change | Info | The HTTP status code changed between two consecutive reachable probes (e.g. 200 → 301, 200 → 403) |
For full details on each alert see the alert reference.
website_down
DomainCare emits website_down when the server is genuinely unreachable — network failures, timeouts, or 5xx server errors. A 4xx response like 403 (Forbidden) or 401 (Unauthorized) means the server is responding and is not treated as downtime. Instead, 4xx responses show as a "Needs attention" warning on your dashboard tile.
A single failed request does not trigger an alert — this prevents false positives from transient network blips.
When you receive this alert, check:
- Whether your server or hosting provider is experiencing an incident.
- Whether a recent deployment broke the server startup.
- Whether a firewall rule or DDoS protection is blocking the probe's IP range.
website_back_online
This recovery alert fires automatically when the probe succeeds again after a website_down event. No action required — it confirms the outage is over.
website_slow_response
DomainCare emits website_slow_response when the response time climbs above 3000 ms (3 seconds).
Common causes: database query bottlenecks, large uncompressed assets, upstream API latency, insufficient server resources.
http_status_code_change
This info-tone alert fires when the status code returned by the probe changes between two consecutive reachable checks — for example, from 200 to 301, from 200 to 403, or from 403 to 404. It covers any status pair where the server responded (2xx, 3xx, or 4xx). It does not indicate an outage by itself but is useful for catching unexpected redirects or access-control changes.
Reading latency stats
The domain dashboard shows a latency chart for the last 24 hours. Each data point represents the response time for a single probe request.
Key metrics shown in the chart tooltip:
- p50 (median) — half of requests responded faster than this value
- p95 — 95% of requests responded faster than this value; highlights occasional slow spikes
- Min / Max — fastest and slowest recorded responses in the selected window
A healthy site typically shows a flat p50 line with occasional p95 spikes. A rising p50 trend over time usually indicates a capacity or query performance issue.