Uptime monitoring that refuses to guess.
Point it at a URL, pick the regions, and it starts checking. No agent, no sidecar, nothing of ours running in your infrastructure.
Free plan: one monitor on 3-minute checks, one status page. No card.
Endpoint
Check from
Interval
30s
Timeout
10s
Expect
200
signed spec → 5 regions, one tick
Queue depth crossed its bound three checks ago. The two slowest regions followed it.
Escalation
- sent
- still open, so step 2 fires
- sent
Each destination is throttled, so one flapping monitor cannot become forty messages.
How it decides
Every alert has a rule behind it. Here they are.
Every monitoring tool promises it will not wake you for nothing. These are the four rules that decide, printed rather than promised, so you can check them against the last false alarm you were paged for.
-
One tick, every region
All 5 regions run in the same tick rather than taking turns, so a slow region is a fact about that region and not about where it sat in a queue.
1 job × 5 regions / tick -
One healthy region clears the streak
A single success from anywhere resets the failure count to zero. Which means one region having a bad minute cannot page you on its own.
any non-down result → consecutive_fails = 0 -
Not the first failure, the 2 in a row
An incident opens only once the failure streak crosses the threshold. The default is 2, so a transient flake is absorbed and a sustained outage still opens on the next tick. Adjustable per monitor.
incident_threshold = 2 -
Our failure is not your outage
When our own edge refuses a probe, it is recorded as a configuration problem and shown to you. It does not touch the status, it does not touch the streak, and it pages nobody.
refusal → last_status untouched
And every check records which data centre answered it, so a regional story is evidence rather than a guess.
- US East
- US West
- EU West
- EU Central
- Asia-Pacific
What it inspects
A 200 only means something answered.
Your queue can be forty thousand deep, your certificate can have nine days left, and your endpoint will still cheerfully return 200. So a check here reads more than the code it got back.
- A number out of the response body
- Point a selector at a value your endpoint already returns, give it a bound, and it becomes a first-class signal: charted, thresholded, and able to open an incident on its own. 5 kinds of selector, and you can test one against a live response before you save it.
-
json_path · regex · xpath · header · http_status - The certificate, before it bites
- Every tracked monitor has its TLS certificate read on a schedule. Inside the warning window an incident opens once, not once per run, and the expiry date is on the monitor where you can see it coming.
-
ssl_alert_threshold_days = 14 - An error budget, from real checks
- Set a target per monitor and the remaining budget is computed from the checks that actually ran. When there is not enough history to answer, it says so instead of showing you a confident zero.
-
slo_target, per monitor
What came back
{
"status": "ok",
"queue": { "depth": 4812, "workers": 8 },
"build": "2.31.0"
}Selector
$.queue.depth
Bound
warn ≥ 1000
Status pages
During an outage, your quietest channel does the most talking.
A page your customers can reach when nothing else of yours is up. It answers the question before it reaches your inbox, and it keeps answering it after you have gone to bed.
- Components, and groups of components
- 90 days of uptime per component
- Incident history with published postmortems
- Email subscribers, double opt-in
- Your brand colour and logo
- On a path or on its own subdomain
The same page is rendered to an image on every change, so you can see what a customer sees without publishing to find out.
The AI boundary
It reads the measurements, and invents nothing.
An AI that guesses at a cause is worse than no AI at all, because at three in the morning you act on it. So the limits are drawn first: it cites only the checks, regions and metrics it can see, it writes the evidence both for and against, and where it does not know it says so.
What it cannot see
- your deploys, your commits, your CI
- your logs, your traces, your APM
- your CDN, or anybody else's status page
Uptizm watches your endpoints from the outside, and that is the whole of what it knows. So it can tell you the queue crossed its bound three checks before the first 503. It cannot tell you a deploy caused it, and it will not pretend otherwise.
You set what it is allowed to do
- Off
- Thresholds and people open incidents. The AI is not in the loop at all.
- Suggest
- It writes an analysis on incidents and raises what it thinks is an anomaly. You decide.
- Auto
- It opens anomaly incidents itself, keeps them updated, and resolves them when the signal clears.
Its suggestions are advice. There is no button that lets it touch your infrastructure, because it has no way in.
And the AI is in the plan, not billed per incident. Pay-per-use AI sends its biggest invoice on your worst day, and a feature you hesitate to let run is not a feature.
Point it at one URL and see what comes back.
Nothing to install, and nothing to undo if you change your mind. The first monitor takes about as long as reading this sentence.
Free plan: one monitor on 3-minute checks, one status page. No card.