What Is an Uptime Badge and Should You Add One? The Provenance Test

An uptime badge is a small embeddable graphic showing a service's measured availability, usually as a percentage over a recent window, linked to the status page behind it. Whether you should add one comes down to three questions about the number it displays: who measured it, over what period, and what exactly was measured. A badge that cannot answer all three is decoration, and an informed reader will treat it that way.

This article covers what a badge actually contains, the provenance test that determines whether yours means anything, when publishing one helps and when it invites scrutiny you are not ready for, and the failure modes worth knowing before you embed one on a pricing page.

What a badge actually shows

A badge is a small image or embed rendered from live data, typically showing either a current state such as operational or degraded, or a percentage over a trailing window, or both. It usually links to the fuller status page.

The value proposition is that availability claims are cheap to make in marketing copy and expensive to make continuously in public. 99.9% uptime in a feature list is an aspiration nobody can check. A badge showing 99.94% over the last ninety days, updating on its own, is a standing commitment, and buyers who have been burned before understand the difference immediately.

The catch is that a badge compresses a lot of methodology into one number, and the methodology determines whether the number means anything. Two services can both display 99.9% while measuring things so different that comparison is meaningless. This is why the status page examples worth studying tend to publish the definitions alongside the figure rather than the figure alone.

The provenance test

Call this the provenance test, and apply it to your own badge before publishing and to anyone else's before believing it.

Who measured it? A number generated by the vendor's own internal checks is a self-report. It is not worthless, but it is measured by the party with an interest in the result, using infrastructure that shares failure modes with the service. A number from an independent outside-in monitor is a materially stronger claim.

Over what window? Ninety days is the common choice and it is a reasonable one. Rolling thirty days is more responsive and more volatile. All-time is close to meaningless, because a service running for four years can absorb a full day of downtime and still display 99.9%. Any badge that does not state its window is hiding the most important variable, because the window determines how long a bad month stays visible.

What was measured? Availability of what, exactly, and from where? A check against a homepage from one region is a much weaker claim than checks against the login endpoint, the API, and checkout from seventeen locations. The number looks the same. The commitment behind it is not.

A badge answering all three is genuinely persuasive. A badge answering none is a graphic that says a number, and the more sophisticated your buyer, the more likely they are to notice.

When to add one, and when not to

Add a badge when reliability is part of what you sell and you can support the claim. Infrastructure and developer tools benefit most, because the audience knows what the number means and is actively comparing. It also helps if your competitors do not publish one, since the asymmetry itself communicates confidence.

Add one if it will change your internal behaviour, which is an underrated reason. A public number that updates automatically creates a standing incentive that a private dashboard does not. Teams that publish tend to get more careful about the things that quietly degrade availability.

Do not add one if your actual availability will not survive being displayed. This sounds obvious and is regularly ignored. A badge showing 98.2% is worse than no badge, because it converts a vague impression into a specific, checkable, disappointing fact directly on your pricing page.

Do not add one if you cannot commit to keeping it accurate. A badge that has been stuck on one figure for eight months, or that shows operational during an incident your customers are currently experiencing, does more damage than the absence of a badge ever would. And do not add one if you are not prepared for the follow-up question, because publishing a number invites people to ask exactly what it covers.

What to publish alongside it

A badge on its own is a claim. A badge with its definitions is evidence, and the additional material costs very little.

State the measurement window explicitly on the status page, state where the checks run from and how often, and state what counts as downtime, particularly whether partial degradation and scheduled maintenance are included. Scheduled maintenance is the one buyers ask about most, because excluding it is standard practice and quietly makes every number look better.

Publish a history rather than only the current figure. A percentage tells you how much downtime there was; a timeline tells you whether it was one bad afternoon or a persistent pattern, and those are very different products. Incident history matters here too: a service with occasional failures and prompt, detailed communication reads better to an experienced buyer than one with a marginally higher number and no explanations.

If the number comes from an independent monitor rather than your own infrastructure, say so prominently. It is the single strongest thing you can say about a uptime figure, and most vendors cannot say it.

Common mistakes in publishing an uptime badge

Not stating the measurement window. A percentage with no period attached is uninterpretable, and all-time figures conceal outages behind arithmetic. Name the window on the badge or immediately beside it.

Measuring from inside your own infrastructure. Internal checks cannot see failures at the network edge, in DNS, or at the certificate layer, which are exactly the failures customers experience as total outages.

Measuring only the homepage. A landing page stays up when login, the API, and checkout are broken. A badge derived from the easiest possible check overstates availability by design.

Publishing a number you have not stress-tested. Work out what your badge would have displayed during your worst month last year. If that figure would have cost you a deal, fix the availability before publishing the badge.

Letting it go stale. A badge showing operational during a live incident is worse than no badge, because it demonstrates publicly that your reporting is not connected to reality.

FAQ

What is an uptime badge?

A small embeddable graphic showing a service's measured availability, usually as a percentage over a trailing window and often with a current state indicator, linking through to the full status page.

Should I put an uptime badge on my website?

Yes if reliability is part of your value proposition and your real numbers support the claim. No if the figure would be unimpressive, or if you cannot keep it accurate, since a stale or contradicted badge damages trust more than having none.

What uptime percentage is good enough to display?

It depends on what you sell and what your competitors show, but 99.9% over a rolling ninety days is a defensible figure for most business software. Below about 99.5% a public badge usually invites more scrutiny than it deflects.

Can uptime badges be misleading?

Easily, and usually without intent. A badge measuring only a homepage, from one location, over an all-time window, using internal checks, can display a very high number for a service that fails its users regularly. The window and the measurement source matter more than the figure.

Closing thought

The interesting thing about uptime badges is that they are one of the few marketing assets that can be checked. Almost everything else on a pricing page is an assertion, and this is a number that updates whether or not it flatters you. That is exactly why a well-supported badge is persuasive and a poorly supported one is corrosive: the format promises accountability, so any gap between the badge and the customer's experience reads as something worse than an overstatement.

If you are going to publish a number, publish one measured from outside. Odown runs checks from seventeen global locations at intervals down to one minute on every plan, including the twelve dollar tier, and status pages run on your own domain over HTTPS. Availability measured from outside your infrastructure, against the paths that actually matter rather than the homepage, is the version of the number that survives the provenance test.