How quickly will I know about an outage?

Checks run every 15 minutes, and an incident opens once failures are confirmed across consecutive attempts. That is the honest window: this is a scheduled-check product, not a one-second-resolution one.

Can I stop alerts during a deployment?

Yes. Set a maintenance window on the site and alerts are held for its duration while checks and history continue as normal.

Do you monitor from more than one location?

Checks run from a limited set of network locations. That is why a failed check is treated as evidence to confirm rather than proof of a global outage.

Uptime monitoring you can still trust at 3am

An alerting system loses its job the first time it cries wolf. After a handful of false pages, people mute the channel — and the one real outage arrives to an audience that has stopped reading. Everything here is built around that failure mode: confirm before alerting, say what was actually observed, and stay quiet when quiet is the truth.

An unreachable check is evidence, not proof, of an outage — checks run from a limited set of network locations.

Monitor your first site See how it works

Confirmation before escalation

A failed request can mean the site is down, or that one network path had a bad moment. Checks are repeated and must fail consecutively before an incident opens, and the check records what it saw at each attempt — status code, latency, whether DNS resolved, whether the certificate validated — so the incident is a piece of evidence rather than an assertion.

Consecutive-failure confirmation, tuned per site
DNS resolution, TLS validation and response content checked alongside the status code
Recovery detected and announced automatically, with the duration measured rather than estimated
Per-site sensitivity profiles, so a flaky staging box and a storefront are not treated alike

Maintenance windows that actually hold

Planned work should not generate an incident, and an incident during planned work should not reach the client. Schedule a window per site and the pager holds for its duration — the checks keep running and the history stays complete, but nobody is woken for work you are doing on purpose.

Two emails, one outage

Your team gets the diagnostics: HTTP status, latency, probe error, the timestamps. Your client gets a sentence that tells them the site went down, that you were alerted automatically, and whether anything is needed from them. The same event, written twice, because the two readers need different things from it.

Where alerts land

Email by default, with Slack and outbound webhooks alongside it rather than instead of it. Channel health is testable from the app, so a misconfigured webhook is discovered on a Tuesday afternoon and not during the outage it was meant to announce.

Questions people ask

How quickly will I know about an outage?: Checks run every 15 minutes, and an incident opens once failures are confirmed across consecutive attempts. That is the honest window: this is a scheduled-check product, not a one-second-resolution one.
Can I stop alerts during a deployment?: Yes. Set a maintenance window on the site and alerts are held for its duration while checks and history continue as normal.
Do you monitor from more than one location?: Checks run from a limited set of network locations. That is why a failed check is treated as evidence to confirm rather than proof of a global outage.

Point it at a site you already know

One website is free, with the full product — the same checks, alerts, status page and monthly report. Adding a site whose history you already know is a fairer test of SiteIntact than any demo.

Monitor your first site