Website monitoring that verifies an outage first

One failed check is not an outage yet. When a website doesn’t respond, digiWatcher doesn’t wait for the full interval—it checks again within 20 seconds. An alert goes out only after the set number of failed checks in a row; the default is two, and you can change it for each website.

If the digiWatcher operator has enabled additional monitoring locations, a majority of them must confirm the outage, and always at least two. A result nobody else confirmed stays an Unconfirmed issue: you see it in the overview with an explanation, but no alert is sent.

What we don’t treat as an outage

• A firewall, Cloudflare, or the host rejects the check (403 or a challenge page): the website gets the status Checks blocked, not Down.
• The server answers 429 “too many requests”: the site is up and serves people, it just turns the robot away. That is Checks blocked too.
• The website is slow but works: you get a separate slow-response alert, and uptime stays at 100%.
• Scheduled maintenance in a maintenance window: during the window there are no checks and no alerts.

The core is an HTTP(S) check: status code, response time, and redirects. You set the interval for each website; the shortest is 30 s on paid plans and 5 min on the Free plan. Other check types:

• Keyword: a specific text must (or must not) be on the page, such as the add-to-cart button.
• Ping and Port (TCP): server response or an open port for mail, a database, or SSH.
• Heartbeat: a reverse check for scheduled jobs, described below.

You can also set a response time limit for each website. When the site exceeds it in several checks in a row, you find out before the client complains about a slow online store. Slowness doesn’t count against uptime, because the site really works. Advanced HTTP checks support custom headers, the method, a request body, basic auth, and a choice of accepted status codes.

For every HTTP monitor, digiWatcher tracks SSL certificate expiry and warns you ahead of time, 14 days by default. It reads domain registration expiry from public RDAP and reminds you a month, two weeks, a week, and a day before; this works for .cz domains too. A renewed certificate or domain resets the reminders.

Upcoming expirations for all websites are shown together in the overview, so renewing a certificate or a domain doesn’t get lost among other work.

For each website you can turn on a daily broken-link check. It follows internal links up to two levels deep, respects robots.txt, doesn’t submit forms, and skips the admin area, checkout, and URLs with parameters. Broken links and images are grouped by the page they sit on, so you know where to fix them.

Links to other websites are checked only if you opt in, and reported only on a 404, a 410, or a domain that doesn’t exist. Sites that turn robots away aren’t treated as broken. The same check compares DNS records with the values you expect and flags a page blocked from search engines or content loaded over unencrypted HTTP.

Security headers are also checked every day, but only as an overview: they never trigger alerts.

Alerts go out by email or to Slack, Telegram, Microsoft Teams, Google Chat, Discord, ntfy.sh, Pushover, or a generic webhook. For each website you choose which alert contacts to use. The Test button checks a channel right away, not during the first real outage. We don’t recommend email as the only channel; it tends to be the slowest.

• Repeat reminders while the site is down, every 5 minutes to 6 hours if you want them.
• A recovery message including how long the outage lasted.
• Quiet hours: no alerts are sent during the set window, outages are still recorded, and the message arrives when the quiet period ends. You can allow selected websites to wake you anyway.
• Escalation: an outage nobody has acknowledged alerts another contact after the time you set.
• Maintenance windows: one-time, daily, or on selected days, for chosen websites or all of them. Scheduled maintenance doesn’t spoil uptime statistics.

Outages are recorded as incidents, where the team adds notes. Public notes appear for clients on the public status page; internal ones stay with you. What to do when an alert arrives is covered in the manual chapter on alerts and incidents.

Some things can’t be checked from outside: a nightly import, a cron job, or an export to accounting. A Heartbeat check gives you a URL with a random key, and you add one request at the end of the script, for example curl -fsS https://…/api/heartbeat/<key>. When the job doesn’t check in within the set interval and tolerance, digiWatcher reports an outage through the same channels as for a website.

digiWatcher isn’t the cheapest way to ping hundreds of URLs. It pays off for agencies and site managers who look after client websites: monitoring comes together with WordPress health, team work on incidents, and monthly client reports.

The Free plan covers 3 websites at no cost. Start is €12 a month for 10 websites, Profi €32 for 30 websites, and Agency €66 for 100 websites.

Moving from UptimeRobot? Bring your monitors over with the migration guide; they are imported paused and your existing service isn’t changed. See the comparison on the UptimeRobot alternative page.