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 confirmed website_down outage (not after a single transient blip) |
website_slow_response | Warning | Response time stayed above the slow-response threshold across two consecutive checks (a single latency spike is ignored) |
http_status_code_change | Info | The HTTP status code changed and the new code held across two consecutive reachable probes (e.g. 200 → 301); transient blips are ignored |
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.
The website_down alert also tells you that DomainCare has paused this domain's other checks while it's down (see What happens to other checks during an outage). They resume automatically when the site is back online.
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 confirmed website_down outage (one that lasted at least two consecutive checks). A single transient failure that self-resolved on the next probe never raised a website_down, so it produces no website_back_online either — you won't get "back online" notices for blips you were never told about. No action required.
website_slow_response
DomainCare emits website_slow_response when the response time stays above 3000 ms (3 seconds) for two consecutive checks — it fires once at the onset of sustained slowness. A single slow probe (a cold start, a momentary network hiccup) is ignored, and the alert does not repeat while the site stays slow.
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 and the new code holds for two consecutive reachable checks — for example, from 200 to 301, from 200 to 403, or from 403 to 404. Requiring confirmation means a transient 503/429 under momentary load doesn't churn this signal. It covers any status pair where the server responded (2xx, 3xx, or 4xx), does not indicate an outage by itself, and is useful for catching unexpected redirects or access-control changes.
What happens to other checks during an outage
When the uptime check confirms your site is down (two consecutive failed probes — the same gate behind the website_down alert), DomainCare pauses every other check for that domain and keeps running only uptime. The moment the site responds again, the full set of checks resumes on its normal schedule.
This is deliberate. If your site is unreachable, the SSL, redirect, sitemap, robots.txt, security-header, and other checks would all fail too — but only as symptoms of the same outage. Pausing them means you get one clear "website down" alert instead of a flood of misleading failures, and your dashboard shows the outage as a single issue rather than a wall of red.
While paused, those checks display a Paused badge on their dashboard tiles and keep their last-known result (they aren't counted as failures). You can still trigger a manual re-check on any individual check tile if you want to test it during an outage — the pause only applies to automatic and full-domain checks.
During a confirmed outage the domain itself reads Critical everywhere — the uptime tile shows a red Down badge, and the dashboard and domain list count the domain as critical with a "site is down" issue. A single failed probe doesn't do this: until the second consecutive failure confirms the outage, the run shows as grey "Unavailable" (we couldn't observe — possibly a blip), and no alarm is raised.
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.