Why Pingdomain

The check runs where your users are

Schedulers run wherever the platform decides to run them. Ours ended up in Taipei, and every response time silently carried a round trip to Taiwan and back — a Swedish shop's product pages looked like they answered in 1.4 seconds. They answered in 24 milliseconds.

The fix was a probe pinned to each region, and it is the reason a region is chosen per monitor rather than set once for the account. If the probe cannot be reached, the failure is recorded as ours and the location is stored with every single result — because a measurement from the wrong continent is worse than no measurement, and it looks exactly the same on a graph.

The alert threshold counts failures, not state changes

Almost every tool offers "alert after N failures". The naive implementation hangs it on the moment the monitor flips from up to down — which means that with a threshold of three, the alert is suppressed at the flip and then never comes back. The site is down, the threshold is met, and nothing is sent.

Here the count is the failure streak itself, asked before the result is written and compared for equality — so it fires once, exactly at the threshold, not every minute for the length of the outage.

A 403 is data, not a hole in the chart

When a firewall rejects a check, the server answered. There is a status code, and a real response time. Treating that as "no data" is a bug that makes a blocked monitor look like a broken one — we shipped it, and it made six perfectly good measurements at 5–10 ms vanish from the graph, the table and the average at once.

Every response is charted, whatever the code. Only a timeout or a connection failure has no timing to show, and that case is drawn as a marker on the baseline rather than as an invented number. If the body turns out to be a bot challenge — reCAPTCHA, Cloudflare, DataDome and several others are recognised — the error says so, instead of leaving you with "Unexpected status code: 429" and no idea why.

Five hundred pages can be one monitor

A catalogue does not need five hundred rows in a dashboard. Point a monitor at a sitemap with a path pattern — /product/* — and each check pulls one address from the pool, favouring whichever has waited longest. The failure streak is counted per address, so three different dead product pages in a row do not raise an outage, but the same one failing three times does.

The sitemap is re-read on a schedule, pages that disappear are swept out, and robots.txt is honoured for anything discovered that way.

No JavaScript, and that is a feature

The content security policy on this site says script-src 'none', and it says it on the dashboard too. The charts are server-rendered inline SVG, the tooltips are SVG titles, the organisation switcher is a <details> element and a form.

The point is not minimalism. A monitoring tool is opened on a phone, on a train, on the worst connection of your week, in a tab that has been sitting open since yesterday — and a dashboard that needs to boot a framework before it can tell you whether the site is down has failed at the one moment it existed for. It also means cross-site scripting cannot become executable code here, even if we one day slip.

You can read the numbers, whoever you are

Red and green sit at a colour difference of 2.2 for the most common form of colour blindness — measured, not guessed. For a deuteranopic reader, this product's two most important colours are the same colour.

So colour never carries meaning alone: every status badge has an icon and a word, the uptime history encodes failure as height as well as hue, and every chart has a table underneath it. That is also why the interface targets WCAG 2.2 on every change rather than in a cleanup pass later.