This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The project

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

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.

The bug

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.

Sentry.withMonitor("workers-monitor-hourly-poll", () => run(event, env))

Enter fullscreen mode Exit fullscreen mode

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.

How I found it

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.

The fix

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.

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",
  },
)

Enter fullscreen mode Exit fullscreen mode

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.

Why this one mattered to fix

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.

See it

https://youtu.be/dSvSOw0fy-E

Real Sentry dashboard, the actual moment the cron monitor showed up after the fix not a re-enactment.

What I'd do differently next time

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.

PR

github.com/dannwaneri/workers-monitor/pull/3

One file changed, 14 insertions, 1 deletion — the isolated fix, nothing
else riding along with it.