{"schemaVersion":"1.0","type":"Article","types":["Article"],"slug":"four-false-deaths-on-the-same-host-in-four-days-after-the-second-i-retried-with-longer-pauses-the-fourth-walked-through-them-the-verdict-moved-from-the-page-to-the-host-which-my-script-cannot-kill-8x3jm","url":"https://zyvop.com/four-false-deaths-on-the-same-host-in-four-days-after-the-second-i-retried-with-longer-pauses-the-fourth-walked-through-them-the-verdict-moved-from-the-page-to-the-host-which-my-script-cannot-kill-8x3jm","title":"Four false deaths on the same host in four days. After the second I retried with longer pauses; the fourth walked through them. The verdict moved from the page to the host, which my script cannot kill","subtitle":null,"tldr":"I have written twice already about a hosting service that occasionally answers my liveness check with \"not found\" for a page that is perfectly alive.","keywords":[],"entities":["Mathieu Ades","Founder","ZyVOP"],"keyTakeaways":["I have written twice already about a hosting service that occasionally answers my liveness check with \"not found\" for a page that is perfectly alive.","After the second time, I made the check retry a not-found answer three times with a pause between.","After the third, I widened the pauses, three seconds then ten, because three tight retries had all landed inside the same burst."],"headings":["The pattern of the fixes","What changed","The three witnesses","What I gave up","The general shape","Disclosure"],"outboundLinks":[],"contentText":"I have written twice already about a hosting service that occasionally answers my liveness check with \"not found\" for a page that is perfectly alive. After the second time, I made the check retry a not-found answer three times with a pause between. After the third, I widened the pauses, three seconds then ten, because three tight retries had all landed inside the same burst. That was one night. The next morning at three, the check declared a fourth article on the same host dead. Three readings, three seconds apart and then ten, all not found. A minute later, three fetches by hand: 200, the full page, my product's name 85 times, readable by a stranger. The burst had been longer than thirteen seconds. Or there had been two bursts. I do not know and, since that morning, I have stopped trying to outwait it. The pattern of the fixes Each fix so far was a page-level fix. The check looked at one page, got one answer, and I made it ask again, then ask again more slowly. Each fix was reasonable, and each was calibrated on the burst I had just seen, which is the only burst I could see. The next burst was longer. There is no reason to think a third widening would not meet a fifth burst, and every widening costs every genuinely dead page on every host a longer wait before it gets its word. Four events on one host in four days, and none on any other host, is not four page events. It is one host property, observed four times. The fix for a host property lives at the host level. What changed The check now carries a short list of hosts known to answer not found in bursts. For a page on one of those hosts, a not-found answer that survives the retries no longer produces the word dead. It produces the undecided verdict, with the reason spelled out: not found in a burst, host known. The undecided bin is the one I already keep for pages my command line cannot judge, and it is replayed in a real browser once a day. If one of these pages were actually removed, the browser replay would say so, from a different client at a different time, which is a better witness for a removal than three fetches inside one bad minute ever were. Elsewhere, on hosts with no such habit, not found still means dead. The word is not gone from the check; it is withheld from one host that has shown it cannot be trusted with it. The three witnesses A rule that moves a verdict needs to be shown moving it, and shown not moving the others. I loaded the check as a module and asked its classifier three questions. A not-found on the burst host: undecided, host known. A not-found on any other host: dead. A 200 on the burst host with my name in the body: alive. Three answers, exactly the three I wanted, before the rule went into the next pass. What I gave up The ability to learn, from the command line alone, that a page on that host has been removed. That is a real loss, and I want to state it rather than hide it in the reason string. Between the daily browser replay and the next one, a removal on that host would sit in the undecided bin looking like every other false alarm. I have accepted that for one host, because the alternative was four false deaths a week and a check I had started to disbelieve, which is worse than a removal noticed a few hours late. The general shape When the same failure repeats on the same source, there is a point where the honest unit of the rule changes. Before that point, you fix the reading. After it, you fix what the reading is allowed to mean from that source. I passed that point at the fourth event, and I suspect the third was already it. The tell was that each fix had been calibrated on the last failure, which is a fine way to handle a page and a poor way to handle a habit. 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. Everything above comes from distributing it in public and counting how many times the same host fooled the same check. You can find it at blueticks.io.","contentHash":"sha256:46ca68f0cf299f83999f9325477932d018bbd9ae4d191307da2783ed1c49f7ba","authorName":"Mathieu Ades","authorUrl":"https://zyvop.com/author/mathieu","authorSameAs":["https://blueticks.io/"],"category":null,"tags":[],"audience":"Technical professionals and readers researching software development","tone":"Professional, founder perspective","readingTimeMinutes":3,"wordCount":777,"faqs":null,"primaryTopic":null,"publishedAt":"2026-09-17T01:30:17.560Z","updatedAt":"2026-09-17T01:30:17.560Z","canonicalUrl":"https://zyvop.com/four-false-deaths-on-the-same-host-in-four-days-after-the-second-i-retried-with-longer-pauses-the-fourth-walked-through-them-the-verdict-moved-from-the-page-to-the-host-which-my-script-cannot-kill-8x3jm"}