Has it ever said no?

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.

Check something

The three examples are synthetic, written for this page. They are the three shapes the tool distinguishes between.

What it is looking for

Four things, in order of how much they are worth.

  • A demonstrated no. One record where the check said fail, error, false, down, nonzero. That single record is worth more than ten thousand greens, because it is the only direct evidence that the check has a look/see distinction at all.
  • How many distinct values the verdict field has ever taken. A field that has been "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.
  • Lifecycle fields sitting where a verdict should be. completed, done, finished and in_progress say that something ended. They do not say how it ended. Dashboards read them as verdicts constantly.
  • Records that disagree with themselves. A verdict field saying up next to a detail field carrying an HTTP 500. The tool will not tell you which one is right. It will tell you they do not agree, which is the part you can act on.

What it cannot do, said before you find out

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.

Why we built it

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.