Eleven days of green, and the thing it was protecting died anyway

Two failures in the same fortnight, both of which announced themselves as working.

The keepalive

A free-tier Postgres project pauses after a period without activity. The guard against that was a scheduled job doing a daily read, which returned 200 every single day for eleven days. On day eleven an email arrived saying the project was about to be paused for inactivity.

The job was running. The query was succeeding. The status code was honest. And the provider's definition of "sufficient activity" is undocumented and sits somewhere above a single daily read, so eleven consecutive green runs had bought nothing at all.

The fix was to stop relying on an undocumented threshold and pay for a tier that does not pause. What stays useful is the shape of the mistake: a check that measures the wrong thing fails silently and keeps on failing, because every signal it produces says it is fine. A red check gets investigated within the hour. A green one that proves nothing can run for a year.

The enquiry path

The contact form stores the enquiry and then sends a notification. The storage call used fetch with no timeout and no guard. If the store was unreachable, that call threw, the throw escaped the handler, and the whole request returned a 500. Nobody got an enquiry, nobody got a notification, and the visitor saw an error after typing out what they wanted.

The failure mode is the exact opposite of what the code was for. The notification exists so an enquiry is never missed; the storage step was taking the notification down with it.

Now the store call cannot throw. It has an abort controller and a five second timeout, every failure path returns a result object rather than raising, and the notification is attempted regardless. Proved by running it rather than by reading it: 500 before the change, 502 after it locally with the store deliberately unreachable, and 200 in production with everything up.

What both have in common

Each one had a signal that looked like proof and was not. One returned the right status code for the wrong question, and the other had no test at all for the only path that mattered. The useful habit is asking what a check would do if the thing it watches were already broken, and if the honest answer is "pass", it is not a check.