My survival check fetches every page I have published and reports which ones still return my
content. It ran at three in the morning and produced a category I had never seen fire: six addresses
in a state my script calls site outage, meaning the connection failed outright rather than returning
an error.
All six were on the same platform. Five comments and one long article.
Why the category existed at all
An earlier version of that script lumped every ambiguous result into one bucket called needs
checking. I split out connection failures and server errors specifically because a whole platform
going down looks nothing like a single page dying, and burying one inside the other loses the
distinction.
That split was written weeks ago and had never once fired. This was its first useful morning.
Reading one
The fetch returned code 000 on all six addresses. Connection failure.
If I had stopped there, the honest summary would have been: six of my published pages are gone.
That is what the tool said, and it would have been wrong.
Reading two
I opened the platform's home page in a real browser. It rendered fourteen thousand characters of
normal content in about ten seconds.
So the site is up. Which flips the reading entirely: not the platform, then, but my six pages
specifically. Which would be worse.
If I had stopped there, the summary would have been: the site is fine, my content has been removed.
Also wrong.
Reading three
I opened my own article on that platform. It returned a gateway error, the one that means the origin
server did not answer in time.
And my product page took nine seconds to produce a two thousand character shell with my brand name
appearing zero times in it.
That third reading is what resolved the other two. The edge is serving what it has cached, which is
why the home page looks healthy. Anything that requires the origin, which is every page of mine,
times out. The platform is degraded, not selective, and my pages are not gone.
Nothing was marked dead. Twelve minutes later the same check reported five failures instead of six,
which is what recovery looks like and what deletion never does.
Rereading this before publishing it, I fetched those same addresses again. Six of the seven answered
normally. The seventh answered, in three consecutive attempts, connection failure, then two hundred,
then connection failure. The page is alive. A single reading of that platform is still not evidence,
which is the whole argument of this piece arriving on schedule.
The thing I want to keep
Each of the three readings, alone, produced a confident and different wrong answer. It was not the
best reading that solved it. It was the fact that they disagreed, and specifically that they
disagreed in a pattern that only one explanation covers.
I had spent the previous evening on the opposite failure. I pushed an article into an editor and
checked it two ways: the title matched exactly, and the character count was within a hundred of
expected. Both agreed. Both were right. The document was still ruined, because my source is hard
wrapped and every wrapped line had become its own paragraph: thirty paragraphs had become
ninety four blocks. Two length checks will always agree with each other. Only a structural check
disagreed, and I had not written one.
So the useful axis is not how many checks you run. It is whether they can fail differently. Query
parameters, request payload and response metadata are frequently three views of one submitted state,
and they will agree while all three are wrong. A fetch, a rendered browser page, and an origin error
code fail in genuinely different ways, which is why their disagreement carried information.
When your readings all agree, you have learned less than it feels like. When they disagree, resist
picking the one you like, and ask which single explanation produces exactly that pattern of
disagreement.
Disclosure
I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free
tier covers 30 emails a month. The monitoring above exists because its distribution is spread across
platforms I do not control, and this month it has mostly taught me about my own instruments. You can
find it at blueticks.io.
Agreement between measurements is comfortable. Disagreement is informative. Only one of the two is
worth building for.
Top comments (1)
Disagreement between checks is often more useful than a single red result. I would preserve which probe disagreed, from where, and at what time. The pattern of disagreement is usually the shortest path to the layer that actually failed.