Outages confirmed, not false alarms
A single failed attempt is not an outage yet: a deployment, a short server restart, an overloaded proxy. DomainWarn opens an incident only when the website keeps failing beyond the failure threshold, by default five minutes of consecutive failures. As soon as a second monitoring location runs, the outage is additionally confirmed from there before the alert goes out.
When the site comes back, the incident is closed and you receive exactly one all-clear. In between DomainWarn reminds you of the open incident instead of sending a new mail every minute.
What is monitored
For every domain the apex and www are created as separate website monitors; further host names such as shop. or app. you add yourself or accept from the suggestions:
- Availability and status code: connection errors, timeouts and 5xx open a downtime incident; other unexpected status codes a warning. Which codes are expected you define per monitor.
- Response time: if the response exceeds the slow threshold (default 5 seconds) three times in a row, a "slow" incident is created.
- HTTPS stays HTTPS: if the encrypted address redirects to http://, it is reported immediately.
- Redirects: http, https, with and without www must end up at the same canonical address. Diverging targets, a missing redirect to https, long chains and temporary redirects are detected; when the target changes you see before and after.
- IPv6: if the host name has AAAA records, the website must also respond over IPv6. A broken IPv6 path hits exactly the visitors whose provider prefers IPv6 and often goes unnoticed in your own office.
- Page content: per monitor up to ten texts that must or must not appear on the page, checked in the visible text without scripts and markup. A missing "Add to cart" or a sudden "Maintenance" opens an incident.
- Security headers: HSTS, Content-Security-Policy, nosniff, framing protection, referrer and permissions policy and exposed server versions as hints without an alarm, switchable per monitor.
- Subdomain discovery: from the Certificate Transparency logs DomainWarn learns about host names that received certificates and suggests them as website monitors. A certificate for an unknown host name shortly after a name server change is reported as critical.
Settings per monitor
Every website monitor has its own interval within the limits of the plan, its expected status codes, its slow threshold and its content texts. A monitor can be paused without deleting it, and a maintenance window keeps planned migrations out of the alerts.
Compared to uptime tools
An uptime service answers one question: does the address respond? DomainWarn asks the questions that follow: with which code, how fast, at which address, over both IP versions, with which content and which headers. And because the website is only one part of the domain, certificate, DNS, mail records and registration sit next to it in the same overview.
Frequently asked questions
- How fast is an outage reported?
- The website is checked in the interval of the plan: every minute on Agency, every five minutes on Freelancer, every 15 minutes on Free. The incident opens once the failures persist for five minutes; with one-minute checks that is the fifth failure. A single hiccup does not produce an alert.
- Does DomainWarn check from several locations?
- Checks run from a data centre in Germany. A second monitoring location that confirms outages before the alert is available on request on the Agency plan.
- Can I monitor a login area or an API?
- Any publicly reachable address, yes: as an additional host name or as a separate website monitor with an expected status code, for example 401 for a protected area. DomainWarn does not perform logins.
- Do I need IPv6 in my office to use the IPv6 check?
- No, DomainWarn checks from its own network and verifies its own IPv6 path before every finding. If a host name has no AAAA records, that is a hint, not an alarm.