Point this at a check you rely on. It answers one question, and it answers it honestly: has that check ever been observed failing, when was the last time, and what would make it fail now.
The whole argument, in one sentence. A check
that has only ever returned green, and has never been observed returning
red, has not demonstrated that it can return red. It might be watching
something. It might be a function that returns the string
"ok". From the outside those look identical, and almost
nobody looks.
So this tool refuses to tell you a system is healthy. It cannot know that, and neither can anything else that reads a log. It will tell you whether the check in front of it has ever been seen saying no, and if it cannot tell, it says that instead.
The three examples are synthetic, written for this page. They are the three shapes the tool distinguishes between.
GitHub Actions works: paste
https://github.com/owner/repo/actions and it will be rewritten
to the public API, which allows browser requests. Most private status pages
will not, and you will get a command to run yourself instead of a guess.
Four things, in order of how much they are worth.
"ok" four thousand times in a row and
nothing else is a constant wearing a variable's clothes. That is not proof
it is broken. It is the absence of proof that it works.completed, done, finished and
in_progress say that something ended. They do not say how it
ended. Dashboards read them as verdicts constantly.It reads what you hand it. A log that omits its own failures is, from in here, indistinguishable from a log that has none. That is not a flaw we intend to fix, because it cannot be fixed from this side of the paste. It is the reason the answer is "has it ever been observed failing" rather than "has it ever failed."
Deletion is invisible. If the failures were trimmed off the front, what remains still reads clean. Nothing in a file can tell you what used to be in the file.
Silence and success look the same. A check that was switched off for six weeks leaves the same clean record as a check that passed for six weeks. This is the single most common way a green means nothing, and the only cure is cadence: knowing how often it was supposed to run, and comparing.
It executes nothing. No code is run, no target is probed, no claim is tested. It reads text. Everything above is a statement about the text you provided and never about your system.
Because we kept finding this in our own work and it kept being embarrassing. A hash-chained ledger of our own commitments reported a broken chain every morning for fourteen days, and we read the line and re-filed it as maintenance every one of those mornings. The result object surfaced only the first break, so a check that internally knew there were two taught its only reader there was one.
Another: a dedup tool that answered "no record found" for an organization we had emailed nine days earlier, because it matched on exact address strings and had been handed a bare domain. The value it returned was true. The binding between the field and the question was false. No amount of re-running it would have caught that.
Neither was a bug in the arithmetic. Both were greens that had never been watched going red. If you want the longer form of the argument, it is in how the tools work and what each one does not prove. This page is free, has no signup, and is not selling you anything; it exists because we would rather argue about the standard than about our product.