What broke
The alert channel was dead for seven days while the status page stayed green
On 19 September the push service answered 410, the stock app's only push subscription was deleted, and 44 alerts reached nobody for seven days. The status check Claude had written checked whether push was configured, not whether alerts arrived, so it stayed green the whole time.
The short version
What went wrongThe push subscription was deleted after a 410, and 44 alerts reached nobody for seven days. The status check only tested whether push was configured, so it stayed green.
How we found itHenning asked Claude to look at the alert channel on 26 September. The stored alerts' delivery flags showed 0 of 44 delivered since 19 September.
The rule nowA watchdog must measure the outcome, not the setup. Count subscribers and check that recent alerts went out. Feed that to fault tracking and show it somewhere that doesn't depend on the checked channel.
This post documents something Claude got wrong. The claim rests on a commit or a file, not on memory. All of Claude's mistakes
The stock app sends Henning alerts as web push notifications to his phone. For seven days in September none of them arrived. Over that week the app’s own status page said the alert channel was fine.
Claude wrote the check, and Claude wrote the fix. The fix commit sums it up in one line: the channel “was dead for seven days without anything saying so — measure delivery, repair yourself.”
What happened
On 19 September the push service answered a delivery attempt with HTTP 410. A 410 means the subscription is gone: the device has dropped or rotated it. The server did what the web push spec says to do with a 410 and deleted the subscription. That was correct. The problem was that it was the only subscription, and nothing created a new one.
From then on every alert the app produced was stored, but none were delivered. The app keeps each alert in a table along with flags for whether it went out by push or by email. When we looked at those flags afterwards, they showed push delivered every day up to and including 18 September, and then 0 of 44.
Why the status page stayed green
The status page has a check called the notification channel. It existed because of an earlier, similar problem. A comment in the code notes that alerts had once disappeared silently because there were no subscribers and no email key, and that a dark delivery channel should show up on the status page.
The check Claude wrote did not do what the comment asked. It only asked whether a channel was configured: were the push keys present, was an email key present? If either was, it reported “ok”. During the seven days the push keys were still there. So the check was green, with zero subscribers and a growing number of undelivered alerts.
The failure log entry Claude wrote with the fix puts it this way: the check read CONFIGURATION, not DELIVERY.
There was a second gap. The app also has a fault register, a background job that turns red status checks into tracked faults. The notification-channel check was on that job’s list of checks to ignore on purpose. So even a red result would not have become a fault.
A third point is in the same log entry: “the only channel that could have said that push was dead was push.”
The fix commit logs this as a new occurrence of a failure class already in the project’s list of failure classes. The pattern had been seen before.
How it was found
On 26 September Henning asked Claude to “look at the alert channel”. The delivery flags on the stored alerts showed what had happened.
Once the new check was in place, its first measurement came back stale: 44 alerts undelivered since 19 September.
What changed
The fix commit (26 September) changes four things.
The check now measures delivery. A new delivery-status function counts current push subscribers and reads the delivery flags on the most recent alerts. It counts how many of the latest alerts in a row went undelivered, and since when. The rules:
- No channel configured at all: warning.
- Push configured, zero subscribers and no email: stale, with the number of undelivered alerts and the time they started piling up.
- Subscribers exist, but the last three or more alerts were not delivered: stale. The push service is rejecting them.
- One or two recent alerts undelivered: warning.
- Otherwise ok, showing the number of devices and when an alert was last delivered.
This result now feeds the status page.
The fault register no longer ignores it. The notification channel was taken off the ignore list. The fault register’s documentation now says the check is included because it measures actual delivery, not just configuration.
The app itself is the second channel. The bell in the app’s menu reads the push status and blinks a “!” when push reaches no device. If push is dead, Henning sees it the next time he opens the app, whether or not an alert arrives.
The client repairs itself. The service worker now listens for the browser’s subscription-change event. When the browser rotates or expires a subscription, the service worker subscribes again and registers the new endpoint with the server. Separately, every visit to the app now quietly renews the subscription if notification permission has already been given. A 410 followed by a deleted subscription should now be followed by a new subscription, not by silence.
The rule
A watchdog has to measure the outcome, not whether the setup exists. “Configured” is not “delivered”. For an alert channel that means counting subscribers and reading whether the latest alerts actually went out, putting that result where faults get tracked, and showing it somewhere that does not depend on the channel being checked.