False positive prevention that confirms every website outage

Uptimia pages you only for outages that other locations have seen too. Every failed check is re-checked from up to 3 other locations before an incident opens, and the alert waits out the delay you set, so a short outage that heals pages nobody.

Start free trial → See what gets filtered out
30-day free trial No credit card GDPR-ready

Which failed checks become alerts

In a normal week a website monitor records failures that were never outages. Seen from the one location that ran the check, packets dropped on the checkpoint's own route look exactly like a site that is down.

A monitor that alerts on every failed check would have paged you eleven times that week. Uptimia sent a single alert, for the real outage, after four separate locations had seen it. The nine blips stay in the check log with the location that saw each one, and the restart is on record as an incident that paged nobody.

Backup checks before an incident opens

When one location reports a failure, the same check is queued straight away for 3 other locations. The round ends as soon as one of them loads the page, and an incident opens only if all three fail as well.

Recovery takes one passing check. The first location that loads the page again closes the incident, and everyone who was alerted gets the all-clear with the length of the downtime. leans toward up

Where the confirming locations appear

The locations that confirmed an outage stay attached to it wherever you open it.

Confirmed by 3 locations

The alert opens with Down since, the error and the number of confirming locations. Below them comes each checkpoint that detected the outage, with its flag, error and status, then the headers, body, screenshot and traceroute when the probe captured them.

Root cause and timeline

Each incident has its own page with the root-cause panel on top, the table of checkpoints that detected it, and a timeline from the first failed check to the recovery, including every alert that was sent.

Unconfirmed failures in the check log

Failures that never became incidents stay as rows with When, Result, Location and Response time. Filter the Logs page to failing checks and to the locations you pick, and a recurring blip from one region shows up as a pattern.

Start a monitor with outage confirmation.Each alert lists the locations that confirmed it.

Backup checks go out the moment a check fails.

Start your free 30-day trial →
30 days free no credit card cancel anytime

Confirmation, delay and timeout settings

Each one is set per monitor, so a checkout can page you on the first confirmed failure while a staging API waits five minutes.

Backup checks before an incident

Require 1, 2 or 3 other locations to see the failure before the incident opens. Three is the default, and each must be a different probe. On API monitors the first failed run counts as one.

Hold the alert through short outages

A confirmed outage waits this long before anyone is paged, from 0 to 30 minutes. If the site is back first, the queued alert is dropped and the incident stays on record.

How long a check may run

A check still running after the timeout fails and is confirmed like any other failure. The default of 30 seconds suits most pages. A slow report may need longer, and an API that must answer fast can be held to less.

  • Confirmation and delay stack. A blip has to get past the backup checks first, then outlast the delay, before anyone is paged.
  • Lower either one to be paged sooner. Keep an endpoint that hiccups often on three backup checks and a five-minute delay.
  • Neither setting slows recovery. The first passing check closes the incident, however high you set them.
Explore downtime alerts → Explore maintenance windows →
Keyword rules

Error pages that return 200 OK

An error page served with HTTP 200 passes every status-code check, even while your customers read a stack trace on it. A keyword rule makes the check read the page itself and fail on words that should never be there.

  • Text the page must contain. The check fails when any of it is missing.
  • Banned strings. The check fails on text such as "out of stock", "database error" or a framework's error banner.
  • Confirmed like any failure. A failed keyword rule triggers the same backup checks, so one cache node serving a stale page won't page you on its own.
Explore keyword monitoring → Explore monitoring assertions →

Also included

Published probe addresses

The full IPv4 and IPv6 list on a public page, as plain text or in nginx allowlist syntax. Point your firewall rule at that URL and admit the whole list, with no addresses to copy by hand.

203.0.113.17203.0.113.42198.51.100.82001:db8:4f::212001:db8:4f::/64 … and the rest of the list
IPv4 · IPv6 · nginx allowlist

Free ping and traceroute

When a blip looks suspicious, ping or trace the host from outside yourself, with no monitor to set up.

Ping test · Traceroute

Quiet hours per person

Each person sets the hours they take alerts. One that lands outside them is held and delivered when their window opens.

Quiet hours 22:00–08:00 · alert at 03:14
held → delivered at 08:00

Heartbeats & cron

A cron job that runs a minute late is still working. You set a grace period, and a ping counts as missed only once it is later than that.

Expected 03:00 · grace 2 min
ping 03:01 → on time · grace 2 min

Global network

Check from 171+ checkpoints in 70+ countries, or only from the regions you serve with a built-in profile such as Europe or Asia.

Europe · Asia · 6+ probes

Confirmation beyond uptime checks

Certificates, domains, page speed, checkout flows, APIs and DNS records each get their own 1-to-3 confirmation setting, so one probe's bad minute won't page you there either. On API and DNS monitors, a setting of 1 alerts on the first failed check.

UptimeSSLDomainSpeedTransactionAPIDNS

False alarms that every location sees

Backup checks agree on these, so they can't filter them out. A monitor setting handles each one.

Example 1Uptime monitor

A bot firewall challenging the checks

The site loads for everyone you ask, yet the monitor reports it down. Each location gets a 403 and a few hundred bytes of challenge page where your HTML should be, because the bot protection in front of the site has started treating the checks as bots.

Monitor settings Outage confirmation3 backup checks LocationsAll locations Alert delay5 min
What you see and what happens →
What you see
The incident stores the response body the probe received, so the challenge page is there to read before anyone opens a browser.
What happens
Four locations agree the site is refusing them, so this one pages you, and the stored challenge page points to the firewall. Allow the full published probe list, IPv4 and IPv6, and exempt the Uptimia user agent from bot rules. The next check passes, the incident closes and you get the recovery notice. A rule that blocks one country or a small region usually stops here, because backup checks from your other selected locations load the page. Get the probe IP list →
Example 2Uptime monitor

A nightly deploy restarts the app

The release takes the app offline for 3 minutes every night. Three other locations would confirm that outage, because it is real. Since it is planned work, nobody should be woken for it, and those minutes should not count against your uptime.

Monitor settings Maintenance windowDaily · 02:00–02:10 Outage confirmation3 backup checks Alert delay5 min
What you see and what happens →
What you see
The window shows in your history as planned work, and the minutes inside it stay out of the uptime figure.
What happens
Checks pause inside the window and nobody is paged. When the release slot changes, editing the window once updates every monitor it covers. Without a window, a restart shorter than the alert delay still opens an incident on record, though no alert goes out. Explore maintenance windows →
Example 3Uptime monitor

A slow page tripping a tight timeout

A search page takes 12 seconds under evening load, and the monitor's timeout was set to 10. Every location gives up at 10 seconds, so the backup checks agree and the incident opens, even though the page was answering the whole time.

Monitor settings Timeout10 s → 30 s Outage confirmation3 backup checks Alert delay5 min
What you see and what happens →
What you see
The incident lists each location with the same error, a check still running after 10 seconds, and the response-time chart shows the climb in the checks before it.
What happens
Raise the timeout on that monitor to the slowest response you will accept, up to 100 seconds. The same checks then pass, marked slow, and the slowness stays on the chart. If you do want a page for slowness, an API monitor with a response-time budget can send one. Explore response time monitoring →

Set the confirmation per monitoron your own sites.

Pick 1, 2 or 3 backup checks and an alert delay from 0 to 30 minutes.

Start your free 30-day trial →
30 days free no credit card cancel anytime

How false positive prevention works

Uptimia re-checks every failed check from up to 3 other locations and opens an incident only when they agree. The alert then waits out the delay you set and arrives with the confirming locations and what each one saw.

01What causes false positives in website monitoring?+
Usually something on the observer's side: a checkpoint's own network blip, a firewall blocking one region, a single DNS resolver misfiring, a timeout set tighter than your slowest page, or a check landing mid-deploy. Most of these show up at one vantage point only, so Uptimia waits for other locations to see a failure too before paging you.
02How does Uptimia confirm an outage is real?+
When a check fails, Uptimia re-checks right away from other, distinct probes, leaving out the one that raised the alarm. The incident opens and the alert goes out only when the number of confirmations you set (up to 3) agree. On API monitors, that number includes the first failed check. The alert lists the confirming locations and what each one saw. Confirmation counts distinct probes, so one probe answering twice never meets the threshold on its own.
03Can I control how strict the confirmation is?+
Yes, per monitor. Choose 1, 2 or 3 confirmations; three is the default and suits most monitors. On uptime, SSL, speed, domain and transaction monitors, that many other locations must also see the failure. On API monitors the count includes the first failed run, and on API and DNS monitors a setting of 1 alerts on the first failure alone. The editor explains the trade-off for each type.
04What happens when only one region sees a problem?+
No incident opens and nobody is paged unless other locations confirm. The failed check stays in the log as evidence, which helps the day a real regional block appears. If one region matters on its own, give it its own monitor bound to a location profile such as Europe or Asia, so that region has its own incidents.
05How do I stop alerts for sites that flap?+
Outage confirmation filters out the blips that were never real, and the alert delay holds the notification until a confirmed failure has lasted as long as you choose (from 0 to 30 minutes, 5 by default). A service that recovers inside the delay has its queued alert dropped, but the incident is still recorded, so you can see how often it happens.
06How long from the failure to the alert?+
The confirmation round starts as soon as the first failure arrives. Backup checks are queued straight away, without waiting for the next scheduled check. The alert then waits for the delay you set on the monitor, and with the delay at 0 it is sent the moment the last confirming probe answers.
07Does a slow response trigger a false "down"?+
A slow response is recorded as response time. A check only fails when the server passes the timeout you set (30 seconds by default, up to 100), answers with an error, or a keyword rule fails. Even then, other locations confirm before anyone is paged. If your slowest page needs longer, raise the timeout on that monitor.
08My WAF or CDN blocks the checks. Which IPs do I allowlist?+
Every probe address is published at uptimia.com/monitoring-checkpoint-ips (plain text, IPv4 and IPv6, no account needed) and at /monitoring-checkpoint-ips-whitelist in nginx allowlist syntax. Point your rule at the URL, allowlist both protocols, and exempt the Uptimia user agent from bot-signature and minimum-browser-version rules as well as rate limiting. If alerts continue, open the incident, where the response body the probe received is stored. Plain-text probe list · nginx allowlist
09I block some countries on purpose. Will those checks alert?+
Only if enough other locations agree. A deliberate block usually shows as one region failing with 403 while the rest pass. To cut those failures from the log, check from the regions you serve. Pick at least 6 probes yourself, so backup checks stay in your set, or use a built-in location profile such as Europe. A few locations run on a server in a neighbouring country.
10Why does a keyword check fail while the page looks fine?+
The check reads the HTML the server sends, so text that a script adds after the page loads is not there, and copy that marketing rewrote last week no longer matches. Match short text the server renders itself. Banned error strings also hold up better than required wording, which changes whenever the copy does.
11Do heartbeat and server monitors confirm the same way?+
They have no probe to re-check from, so they use their own guards. A heartbeat monitor waits out the grace period you set before a late ping counts as missed. Server monitors report from your own host with the agent, which spools reports it could not send and is only treated as offline after three missed report intervals.
12Is confirmation included on every plan?+
Yes. Confirmation and the alert delay run on every plan, the free one included. The free plan watches 1 website at 5-minute intervals, and the 30-day trial opens every monitor type, no credit card.

Get paged only for confirmed outages

Failed website checks are re-checked from other locations before an incident opens, and the alert lists the locations that confirmed it.

Start free trial →
30-day free trial Backup checks from up to 3 locations Confirming locations in each alert No credit card
Confirmation is on from the first check, with nothing to set up.