Docs · The checks
What Keelnest checks.
Every five minutes, every watched application is asked the one question that matters: does somebody typing this address into a browser get a working site? Everything else is built on top of that answer.
Every five minutes
An ordinary request for the production URL, the way a browser would make it, then the certificate and the security headers. The answer is one of three states:
- Healthy. The page answered 2xx over HTTPS, in time, and the headers are sane.
- Degraded. Something is off but visitors can still use the site: a slow answer, a redirect down to plain HTTP, a missing header, or a status that is unusual without being an outage. Shown on the screens, never sent to anybody’s inbox.
- Critical. The site could not be reached, answered a 5xx, or answered one of the 4xx statuses below that mean a visitor gets nothing. An incident opens after the failure is seen on two consecutive checks, so a single blip never pages anyone.
What each 4xx means for your visitors
The monitor does not file every 4xx as the same thing. A visitor experiences 404 as the site being gone; nobody experiences 429 that way, because it is the monitor being throttled and not the public. Only the statuses where the honest answer to “does a visitor get a working site” is no open an incident.
| Status | Read as | Opens an incident |
|---|---|---|
| HTTP 400 | Site is failing: the server rejects a plain request. The server would not accept an ordinary request for the page. | Yes |
| HTTP 401 | Site is asking visitors for a password. The page is behind a password prompt. | Yes |
| HTTP 402 | Site is switched off by its host. The host is refusing to serve the site until something is paid. | Yes |
| HTTP 403 | Site is refusing visitors. The page is being refused rather than served. | Yes |
| HTTP 404 | Site is gone: the production URL returns HTTP 404. There is nothing at this address. | Yes |
| HTTP 410 | Site is gone: the production URL returns HTTP 410. The address is being reported as permanently removed. | Yes |
| HTTP 451 | Site is blocked for legal reasons. The host or a network in front of it is blocking the page. | Yes |
| HTTP 429 | Site is rate limiting our checks. Our monitor is being rate limited, so we cannot see the page. Your visitors may be fine. | No — degraded |
401 and 403 are the two that can be a firewall singling out the monitor while real visitors are fine; the incident says so and tells you how to tell in ten seconds — open the address in a private window. A 4xx not in the table is recorded as unusual and never alerted on.
The six guards
The five-minute check is the floor. Each connected provider adds one of these on top:
- Money. Payments against a learned baseline, webhook health, checkout evidence. Stripe.
- Publishes. Every deploy gets a verdict within five minutes. Vercel, Netlify, Cloudflare Pages, Render, Fly.io, Railway.
- Backend. Database and auth health, config drift, security advisors. Supabase.
- Spend. AI and hosting usage against budgets, spike alerts. OpenAI, Anthropic.
- Errors. Runtime errors so incidents say what broke. Sentry, Error capture.
- Code. What changed in each publish, and later, repairs. GitHub.
Journeys
A journey is the steps a customer takes — sign in, add to basket, reach the pay step — written in the builder’s language and walked in a real browser on the schedule your plan sets, and again after every publish. A step that fails is retried before anything is said, so a verdict is never one bad run. A payment journey stops before the pay step: nothing is ever charged.
What is kept, and for how long
Observation data is kept for a fixed window per kind — payments, AI usage and daily spend for 62 days, HTTP, SSL and header checks for 62 days, journey runs for 62 days, error events for 15 days — and deleted afterwards. The window is the same on every tier, and a daily check confirms the database is actually obeying it. Failure screenshots are kept for 30 days. One attached to an incident is evidence: it is kept for as long as that incident is open, and for 30 days after it closes. The workspace activity feed is kept for 365 days.