Oh Dear Alternative from Germany

Why does Oh Dear bill per website?

Because that is the unit its audience thinks in. Agencies, freelancers and studios look after a countable set of client sites, and each is a self-contained unit with its own domain, its own certificate, its own sitemap and its own invoice to the client. €15 for two sites, €49 for ten, €99 for twenty-five — that scale can be passed on to a client without conversion.

What is notable is what the scale does not contain: feature gating. Every plan includes all check types, and team members are unlimited on every plan. That is unusual and welcome, because it removes the most common friction in a pricing decision — weighing whether a single feature is worth a tier jump.

The unit fits exactly as long as "website" is the right thing to count. It stops fitting as soon as a single domain has many separately monitorable things behind it: an API, a payment service, a queue, three background workers, a database, an object store. From a per-site billing view that is one unit. From an operations view it is eight, each of which fails separately and has to be communicated separately.

That yields a simple test question before deciding: does your organisation count websites or services? If the answer to "how many do you monitor?" matches the number of domains, per-site billing is right. If the number named is considerably larger, it is not.

One borderline case deserves mention: the provider who both maintains client sites and runs infrastructure of their own. Here the answer is usually both, and trying to force everything into one billing unit makes one of the two sides expensive.

When is a broken link an incident?

Practically never. A dead link has no urgency, no duration and no affected audience in the sense of an outage. It belongs in a report somebody works through on a Tuesday morning, not in a channel that wakes somebody. Drawing that distinction cleanly is the single most important setting in any tool that checks quality and availability together.

The reason is habituation. Alerting only works while it stays rare. A channel carrying daily messages about Lighthouse scores and dead links stops being read after two weeks — and from then on the message about the real outage goes unnoticed too. The damage comes not from any single unimportant message but from the expectation that messages are unimportant.

The countermeasure is the same regardless of vendor: separate paths. Quality findings go into a weekly digest or a ticket system. Availability incidents go into on-call. There should be no shared channel between them, not even for convenience.

There are exceptions, and they are worth naming. An expiring TLS certificate is a quality finding that becomes an outage — fourteen days out it is a line in a report, two days out it belongs in on-call. The same applies to an expiring domain. Those two cases need escalation over time, and you configure that once.

The third case is the scheduled job that did not run. A failed nightly reconciliation is either a report or an incident depending on what it does — for invoicing, rather the latter. That classification is a business decision rather than a technical one, and it should be made deliberately once and then written down.

What belongs on a status page and what belongs in a report?

The status page carries whatever is currently stopping visitors from doing something. The report carries everything describing an internal quality problem. A dead link on a subpage does not belong on the status page, even though a tool detected it. A payment reconciliation that did not run does belong there, even though no check measured it.

The dividing line runs along the question of who needs the information. A status page has an external audience that visits it at exactly one moment: when something is not working. Anything not concerning that moment dilutes the page and makes it harder to read during an incident. A page with forty components, thirty of which do not interest visitors, answers the actual question worse than one with six.

From that follows a recommendation for structure that holds regardless of tool: name components after what a customer wants to do, not after what technically exists. "Login", "Payments" and "File upload" are good components. "api-gateway-eu-west", "redis-primary" and "worker-queue-3" are not, however technically accurate they may be.

The second point concerns direction. Tools that derive the status page from checks can only show what was measured. That is usually enough — until the day an upstream provider fails, your own checks stay green, and customers still cannot buy anything. A status page on which only check-reported states can be published is silent on that day.

How often does a website need checking for quality?

Far less often than for reachability — and the difference is one of kind, not degree. An uptime check calls an address and takes milliseconds; it can run every minute. A quality check crawls the entire website, follows every link and evaluates every page. Depending on size that takes minutes to hours and makes sense daily or weekly, not by the minute.

Almost everything else follows from that asymmetry. A finding from a daily crawl is on average twelve hours old by the time somebody reads it — entirely fine for a dead link and useless for an outage. The two check types therefore have not only different processes but different notions of time.

In practice that means choosing the cadence from how fast the content changes rather than from instinct. A corporate site touched monthly does not need a daily crawl. A news site publishing a hundred articles a week does. An online shop with rotating stock sits in between and benefits more from a crawl after each publication than from a fixed schedule.

The second point concerns load on the checked site. A full crawl across ten thousand pages is a noticeable burst of traffic that shows up in analytics and, on tightly sized environments, affects response times. It therefore belongs in a period of low usage — not in the morning, when load is highest anyway.

Anyone running both check types in parallel should also schedule the quality crawl so it does not coincide with a maintenance window. Otherwise a planned shutdown produces a list of hundreds of apparently broken links, and the next genuine finding disappears into it.