Inverted checks
Most monitoring answers "is it up?". An inverted check answers the opposite question: is this thing still safely unreachable? The monitor is healthy while the target is down, and alerts fire the moment it starts responding.
When to use it
- Internal services that must never face the internet - admin panels, Kubernetes dashboards, staging environments. If your firewall rule is dropped in a config change, an inverted check pages you before a scanner finds it.
- Database and infrastructure ports - Postgres, Redis, SSH on machines that shouldn't expose them. A Port (TCP) inverted check on
db.example.com:5432is a standing "this port is closed" assertion. - Decommissioned endpoints - retired APIs and old domains should stay retired. Catch a zombie service coming back after a bad deploy or a DNS change.
- Firewall and ACL regressions - any place where "reachable" means a security control silently stopped working.
Enabling it
- Create (or edit) an HTTP(s), Ping, Port, or SMTP monitor
- Open Advanced settings
- Turn on Inverted check
That's it - the same intervals, regions, and alert policies apply. You can also set it via the REST API with "inverted": true on monitor create or update.
How the logic flips
| Target behaviour | Normal monitor | Inverted check |
|---|---|---|
| Connection fails / times out | Down - alerts fire | Up - all is well |
| Responds normally | Up | Down - alerts fire |
| Responds slowly or with an error page | Up or degraded | Down - alerts fire |
Note the last row: any successful response counts as exposure, even a 500 error or a response slower than your degraded threshold. If the target answered at all, it's reachable - which is exactly what an inverted check exists to catch.
Reading the results
- Uptime % means "percentage of time the target stayed unreachable" - 100% is what you want.
- Alerts and incidents use the standard wording: the monitor goes "down" when the target becomes reachable and "recovers" when it stops responding. Semantically correct, just inverted.
- Response times are recorded only when the target responds - i.e. during incidents.
Status page caution
Think twice before putting inverted checks on a public status page. Visitors read "Operational" as "the service works" - for an inverted check it means "safely unreachable", which can confuse anyone who doesn't know the monitor's purpose. Keep them on private status pages, or off status pages entirely.
What inverted checks don't replace
An inverted check probes from Vantaj's regions on your monitor's schedule - it tells you a specific host/port answered a specific probe. It isn't a port scanner or an attack-surface management tool: it won't discover exposures you didn't think to monitor. Use it as a cheap, always-on regression test for the exposures you already know would hurt.
Migrating from Uptime Kuma?
Kuma's "upside-down" monitors import directly as inverted checks - see Import from Uptime Kuma.