The failures nobody reports

The expensive problems in a small business are not the ones that generate complaints, and the widely quoted number for what they cost turns out to be a survey of somebody else's company.

There is a category of failure that produces no signal at all.

A page returns an error and the person closes the tab. A form submits into nothing and the sender assumes you are slow to reply. A payment link expires and the buyer decides they did not need it that much. None of these generate a complaint.

Complaints come from people who have already decided you are worth the effort of complaining to, and that is a small and unrepresentative group.

Everybody else just leaves, and leaving looks exactly like not being interested.

This is the failure mode worth taking most seriously, because it is the one a small site is least equipped to detect. When your baseline is zero, a broken thing and a working thing produce identical data.

The state of the average website is worse than you would guess

The HTTP Archive Web Almanac crawls a large sample of the public web every year and publishes what it finds.

The 2025 SEO chapter reports that meta descriptions are absent from 32.3% of pages on desktop and 32.8% on mobile, that invalid elements appear inside the head section of about 10% of pages, and that 13.3% of requests for a site's robots.txt file return a 404 (Web Almanac, 2025).

These are not exotic failures on obscure sites. They are the ordinary condition of the web, and each one persisted long enough to be caught in an annual crawl. Somebody owns each of those sites. None of them knew.

The worst version of this is the soft 404: a page that has nothing on it but returns a status code of 200 OK, which tells every automated system that everything is fine. Google's own documentation covers this specifically, because a server confidently reporting success while serving nothing is the exact case that monitoring misses (Google Search Central).

A page that is loudly broken gets fixed. A page that is quietly broken gets indexed.

Why normal noise hides the failure

Here is the mechanism that makes this genuinely hard rather than merely careless.

Baymard Institute, aggregating 49 separate studies, puts the average documented online shopping cart abandonment rate at 70.19% (Baymard Institute). Roughly 70% of people who put something in a cart do not buy it, and that is the healthy state.

Now break your checkout. Abandonment goes from 70% to 78%. Is that a bug or a Tuesday?

It is not distinguishable without a baseline you established before the breakage, and most small companies do not have one. The failure is real, it is costing money every day, and it sits comfortably inside the range of ordinary variation. This is why quiet failures last for days or weeks rather than hours.

They are not hidden. They are camouflaged by legitimate noise.

The same is true of a slow reply, a checkout that fails on one browser, or a fulfilment step that silently drops one order in twenty. Each one is small enough to look like variance and persistent enough to matter.

The cost of an unmeasured claim

There is a second, related failure, and it is the one that turns a quiet operational problem into a legal one.

The Federal Trade Commission's Policy Statement Regarding Advertising Substantiation sets out a requirement simpler than most people expect: an advertiser must have a reasonable basis for an objective claim before the claim is disseminated. Not afterwards, when challenged. Firms lacking that basis before the advertisement runs are in violation of Section 5 of the FTC Act (FTC).

Read that against how small companies actually write copy. "Ships in 24 hours." "Replies within an hour." "99.9% uptime." Each is an objective claim about a measurable thing. Each requires that you were measuring it before you said it.

This is where the two failures meet. An unmeasured claim and a quiet failure are the same event seen from two sides. You promised a number you were not tracking, so when the number silently degraded, nothing told you, and the promise kept running on the site for weeks after it stopped being true.

The practical rule: a claim must be attached to something already looked at every week. If nothing on the weekly report measures it, it does not go on the site. That rule removes more sentences than it adds.

The number worth refusing to quote

The standard way to end an article like this is with a figure for what downtime costs per hour. The most commonly cited one says a single hour exceeds $300,000 for over 90% of mid size and large enterprises.

That number is not usable here, and the reason is more useful than the number would have been.

It comes from ITIC's 2024 hourly cost of downtime report, which was a web based survey of more than 1,000 firms globally, conducted between November 2023 and mid March 2024 (ITIC, 2024). The figures are what respondents estimated their own downtime costs to be.

They are reported by the respondents themselves, the sample skews toward organisations large enough to have formal IT operations, and the report is explicit that the population is mid size and large enterprises.

A direct to consumer brand doing five figures a month is not in that sample and has nothing in common with it. Applying that number to a small company is not conservative estimation, it is a category error dressed as rigour.

There is no good public number for what an hour of downtime costs a small ecommerce business. What exists is either enterprise survey data like the above or figures published by companies selling monitoring and backup services. No independent dataset appears to exist at small business scale.

Saying so is the point. The absence of a number is itself the finding, and it means you have to generate your own: your revenue for the period divided by the hours in it, which is crude, yours, and defensible, which is three properties the $300,000 figure does not have.

What the check actually looks like

Nothing sophisticated, because sophistication is not the constraint. The constraint is that somebody looks.

Check the live site rather than the description of the site, and open the pages the way a stranger would: on a phone, not logged in.

The launch QA checklist exists for exactly this, because the failure was never not knowing what to check. It was that checking is boring and gets skipped when nothing appears to be wrong.

And the Friday report builder exists because a weekly page of the same numbers in the same order is the cheapest baseline detector available. You do not need to analyse it. You need last week's version next to this week's, and the difference does the work.

Both run entirely in the browser, need no signup, and work offline.

What to do this week

1. Open your own site as a stranger. Phone, not logged in, not on your own network. Go all the way to the last step before payment. Most people who own a site have not done this in months.

2. Submit your own contact form and time the reply. The public post-mortems above name this silent failure more often than any other, and it costs nothing to test.

3. List every objective claim on your site, then write next to each one where the number comes from. Anything with a blank next to it is either removed this week or measured this week. Those are the only two options (FTC).

4. Write down five numbers today and keep them in one place. Whatever they are, as long as they are the same five every week. Without last week's version you cannot see a change, and seeing the change is the entire job.

5. Calculate your own downtime cost once. Monthly revenue divided by hours in the month. It will be a small number and that is fine. It is yours, and it will tell you honestly whether an outage is an emergency or an annoyance.