I Was Filming a Demo of My Monitoring Tool. The Monitor Wasn't Monitoring.

A developer discovered that their Sentry monitoring integration for a Cloudflare Worker fleet was silently failing. Despite deploying Sentry.withMonitor() without errors, the cron monitor never registered because the schedule configuration was missing. The bug was found only when filming a demo video, not through testing.

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. workers-monitor is a Cloudflare Worker I run to watch a small fleet of my own Workers. Hourly cron, deterministic threshold gate, Claude Haiku judgement only if the gate trips, Telegram alert if Haiku confirms something's actually wrong. A quiet hour makes zero LLM calls. github.com/dannwaneri/workers-monitor https://github.com/dannwaneri/workers-monitor It pages me on Telegram when something's wrong with the fleet it watches. What it didn't have, until recently, was an equivalent safety net for itself — if workers-monitor broke, nobody got told. So I added Sentry: automatic error capture, and Sentry.withMonitor around the hourly run so a dead cron trigger would be caught immediately instead of silently waiting up to 24 hours for the next daily heartbeat to go quiet. I deployed it. A cron tick ran clean. I moved on, fairly pleased with myself. A few days later I sat down to record a demo video of the Sentry integration — screen capture, narration, the whole thing, for a separate part of this challenge. Simple plan: open the Sentry dashboard, show the captured errors, show the cron monitor's check-in, done. I opened the Monitors page to get the screenshot. There was nothing there. Just Sentry's own auto-created generic "Error Monitor" — no workers-monitor-hourly-poll , no Cron-type entry whatsoever, despite the code having run successfully, every hour, for days. I'd been carrying around a completely false belief: that deploying Sentry.withMonitor and watching it execute without error meant it was monitoring. It wasn't. It never had been. js Sentry.withMonitor "workers-monitor-hourly-poll", = run event, env Nothing about this throws. It compiles. It deploys. The wrapped function runs exactly as intended, every hour, on schedule. And it still wasn't doing the one thing it existed to do. By accident, honestly. Not through review, not through testing — I found it because I was trying to film proof that something worked, and the proof wasn't there. If I hadn't been making a video, I might not have looked at that specific dashboard page for weeks. withMonitor 's check-in has nowhere to attach without a schedule — Sentry needs to know what "on time" even means for this monitor before it will create a Cron Monitor entity to check in against. Without that config, the call silently has no monitor to report to. js Sentry.withMonitor "workers-monitor-hourly-poll", = run event, env , { schedule: { type: "crontab", value: "0 " }, // matches the real cron trigger checkinMargin: 5, maxRuntime: 5, timezone: "UTC", }, One config object. I deployed it, then made myself actually wait for a real hourly tick — not a local test, the genuine production cron — before I let myself believe it was fixed. workers-monitor-hourly-poll showed up as a real Cron monitor afterward, "Every hour" schedule and all. Because it's the same lie twice, if I'm honest about it. I built a monitoring tool because I don't trust systems to tell me the truth about their own state unprompted. Then I shipped a piece of that exact tool without applying the same skepticism to itself. "It ran without throwing" is not evidence of "it's doing its job" — I know that, I'd have said it confidently to anyone who asked — and I still fell for the gap between those two claims on my own code, in the one project whose entire purpose is not falling for that gap. Real Sentry dashboard, the actual moment the cron monitor showed up after the fix not a re-enactment. Treat "I deployed it and it didn't error" as a hypothesis, not a conclusion — for every feature, not just the ones I already suspect are fragile. The KV read bug I fixed earlier in this project a separate entry, if you're comparing notes came from a structured spec review. This one came from dumb luck — I happened to need a screenshot. I'd rather it come from the habit than the accident next time. github.com/dannwaneri/workers-monitor/pull/3 https://github.com/dannwaneri/workers-monitor/pull/3 One file changed, 14 insertions, 1 deletion — the isolated fix, nothing else riding along with it.