The Cloudflare Worker That Ran Perfectly and Still Failed Twice

A developer building workers-monitor, a Cloudflare Worker that monitors a fleet of Workers, discovered two bugs where code compiled and ran without errors but failed to perform its intended function. The first bug involved a maintenance-window feature that could silently abort the entire hourly run on a KV read failure, violating the rule that malformed data must fail open. The second bug was that Sentry monitoring for the Worker itself was not actually reporting check-ins despite successful execution, requiring a fix to ensure proper cron monitoring.

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry. workers-monitor is a Cloudflare Worker that watches a small fleet of my own Workers. Hourly cron, pulls fleet metrics from Cloudflare's GraphQL Analytics API, runs a deterministic threshold gate, and only calls Claude Haiku to judge signal-vs-noise if the gate trips. If Haiku confirms something's actually wrong, it sends a Telegram alert. A quiet hour makes zero LLM calls. github.com/dannwaneri/workers-monitor https://github.com/dannwaneri/workers-monitor Real alert history from the deployed Worker — the daily heartbeat, and scrolled back, the genuine incidents this system has actually caught. This submission covers two bugs, found days apart, that turn out to be the same failure mode wearing different clothes: code that compiles, deploys cleanly, and runs without throwing — and still doesn't do the one thing it was written for. "No error" is not the same claim as "working correctly," and both bugs below only exist because that distinction got missed once. workers-monitor has a maintenance-window feature — POST a start/end time and it suppresses Telegram alerts during a planned deploy, without stopping the gate or the logging. The function that reads that window had one non-negotiable rule, written as a comment directly above it: Malformed data fails OPEN returns null → no suppression — a broken window read must never accidentally silence a real incident. The code didn't actually satisfy that comment: async function readMaintenanceWindow env: Env : Promise<MaintenanceWindow | null { const raw = await env.STATE.get MAINTENANCE KEY ; if raw return null; try { const w = JSON.parse raw as MaintenanceWindow; if Number.isNaN Date.parse w.start || Number.isNaN Date.parse w.end { throw new Error "unparseable start/end timestamps" ; } return w; } catch err { console.error / ... / ; return null; } } Only JSON.parse and the timestamp validation sit inside the try block — await env.STATE.get ... on the line above does not. A genuine KV read failure a real outage, not bad data throws an exception nothing in this function catches. It propagates out of readMaintenanceWindow , out of the run function that calls it, and aborts the entire hourly run — not just alert suppression, but the deterministic gate, the Haiku judgement call, and the structured logging for that hour, all of it, silently skipped. Every KV blip during that window meant a full hour of zero fleet visibility, not just a missed alert. I found this via a structured review of the diff against the original spec's acceptance criteria, not a live incident. One criterion was almost word-for-word the comment above the function — the review caught that the code only satisfied half of that sentence. Fixing bug 1 raised an obvious follow-up question: what happens when workers-monitor itself breaks, not the fleet it watches? Nothing — console.error into wrangler tail , unread unless I happened to be watching. So I wired in Sentry: Sentry.withSentry around the handler for automatic error capture, an explicit Sentry.captureException on the deliberately-swallowed exception in the scheduled handler's own catch, and Sentry.withMonitor around the hourly run call so a dead cron trigger gets caught immediately instead of waiting up to 24 hours for the next Telegram heartbeat to go silent. I deployed it, watched a cron tick complete without error, and considered cron monitoring done. It wasn't done. While recording a demo video of the Sentry integration — for a separate piece of this challenge — I opened the Monitors dashboard to screenshot the cron check-in, and there wasn't one. Only Sentry's own auto-created generic "Error Monitor," nothing for workers-monitor-hourly-poll at all, despite the code executing successfully every hour for days. js Sentry.withMonitor "workers-monitor-hourly-poll", = run event, env This isn't wrong syntax. It compiles, deploys, executes the wrapped function fine. But the check-in has nowhere to attach without a schedule — Sentry needs to know what "on time" 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. No error, no warning, just nothing showing up. Exactly the same shape as bug 1: code that runs clean and still isn't doing its job. github.com/dannwaneri/workers-monitor/pull/1 https://github.com/dannwaneri/workers-monitor/pull/1 — the fail-open fix, isolated, 12 insertions / 1 deletion. github.com/dannwaneri/workers-monitor/pull/3 https://github.com/dannwaneri/workers-monitor/pull/3 — the cron monitor fix, isolated, 14 insertions / 1 deletion. // Bug 1 fix — env.STATE.get gets its own try/catch, separate from the // existing one around JSON.parse: async function readMaintenanceWindow env: Env : Promise<MaintenanceWindow | null { let raw: string | null; try { raw = await env.STATE.get MAINTENANCE KEY ; } catch err { console.error JSON.stringify { event: "maintenance window read error", error: err instanceof Error ? err.message : String err , } ; return null; } if raw return null; try { const w = JSON.parse raw as MaintenanceWindow; if Number.isNaN Date.parse w.start || Number.isNaN Date.parse w.end { throw new Error "unparseable start/end timestamps" ; } return w; } catch err { console.error / ... / ; return null; } } // Bug 2 fix — the missing monitorConfig, matching the real deployed schedule: Sentry.withMonitor "workers-monitor-hourly-poll", = run event, env , { schedule: { type: "crontab", value: "0 " }, // matches wrangler.jsonc's trigger checkinMargin: 5, // minutes late before considered missed maxRuntime: 5, // minutes before considered timed out timezone: "UTC", // Cloudflare cron triggers always run in UTC }, Neither fix is large. What connects them is how each was actually verified, not assumed: For bug 1, I ran a two-part review before trusting the diff: does it satisfy every Given/When/Then acceptance criterion from the original spec, and separately, does it resolve every assumption flagged during design, including ones nobody had explicitly revisited. That second check is what surfaced it — the acceptance criterion for KV-failure behavior was already written down before the code existed, and the implementation simply didn't fully match its own spec. For bug 2, the same discipline applied to my own claim: I'd told myself "deployed, ran without error, cron monitoring is working." I checked the Monitors dashboard before the fix empty — confirmed the bug was real, not a hunch , deployed the fix, waited for a genuine production cron tick — not a local test, not a manual trigger — and only considered it done once workers-monitor-hourly-poll actually appeared as a registered Cron monitor with an "Every hour" schedule. The broader lesson, true of both bugs: "the code deployed and nothing crashed" is a dramatically weaker claim than "the thing I built does what I said it does." Those two can look identical from a terminal and be completely different in reality. Both Error Monitoring and Cron Monitoring are used here, and bug 2 is specifically about making the Cron Monitoring half actually work as intended, not just installed: Sentry.withSentry wraps the handler, instrumenting fetch and scheduled . try/catch so one bad run doesn't crash the Worker. That's exactly the case withSentry 's automatic uncaught-exception capture can't see, since the exception is caught before it ever becomes "uncaught" — so the catch block also calls Sentry.captureException err directly. workers-monitor-hourly-poll shows up as a real Cron monitor with an "Every hour" schedule. If the trigger stops firing entirely, Sentry now catches that immediately, instead of the previous 24-hour blind spot the daily Telegram heartbeat was the only prior proof-of-life . Verified, not assumed , on both fronts: for error capture, I deployed a temporary route that threw an intentional error, confirmed it was captured in the Sentry dashboard, then removed the route before opening the PR. For cron monitoring, the Monitors dashboard was checked empty before the fix and populated after a real hourly tick — not a claim, a before/after I watched happen. The resolved issues, the real stack trace, and the moment the cron monitor actually registered — the same evidence, on screen.