◉CLAUDE LABJP
●2.1.283 — No Claude Code release over the weekend; 2.1.283 from September 25 is still the latest. Its new auto-mode default deserves a check against your allow rules●PLANS — Pro and Team Standard now default to Opus instead of Sonnet, a change shipped in Claude Code 2.1.280 that shifts how you compare plans●10/07 — Nine days left until the old spellings of the Claude Desktop / Cowork managed config keys stop being accepted; after that they fail closed●AUTO — Users are asking why commands covered by allow rules get rejected in auto mode. The fix is shaping the invoked command to match the rule●NEW — The week Opus 5.5 became the default: three places an alias was still pointing at the old model●CURSOR — Cursor credits burn in proportion to model cost, so routing Claude through Cursor gets expensive fast. Above ~50 requests a day, flat-rate Claude Code Pro is the steadier choice●2.1.283 — No Claude Code release over the weekend; 2.1.283 from September 25 is still the latest. Its new auto-mode default deserves a check against your allow rules●PLANS — Pro and Team Standard now default to Opus instead of Sonnet, a change shipped in Claude Code 2.1.280 that shifts how you compare plans●10/07 — Nine days left until the old spellings of the Claude Desktop / Cowork managed config keys stop being accepted; after that they fail closed●AUTO — Users are asking why commands covered by allow rules get rejected in auto mode. The fix is shaping the invoked command to match the rule●NEW — The week Opus 5.5 became the default: three places an alias was still pointing at the old model●CURSOR — Cursor credits burn in proportion to model cost, so routing Claude through Cursor gets expensive fast. Above ~50 requests a day, flat-rate Claude Code Pro is the steadier choice
Articles/Claude Code
⟐ Claude Code/2026-06-19Advanced

Noticing From the Outside When a Scheduled Job Quietly Did Nothing

exit 0, but zero output. How to catch a silent no-op not from the job's own log but from an external heartbeat ledger and ground truth, written from running several sites on a nightly schedule as an indie developer.

Claude Code257automation110scheduled tasks13observability21reliability18

✦ Premium Article

One morning I opened the update log and a single line was missing — the line for a generation job that should have run overnight. The error log held nothing. The exit code was 0. So as far as the system was concerned, it had succeeded, yet not a single article had been added. There was no commit at that time in the git history either.

That state — "succeeded, but nothing was produced" — was the hardest to deal with. A crash is easier; at least you notice. This failed in silence, and worse, it believed it had succeeded. When you run several sites in sequence overnight as an indie developer, these silent no-ops slip in now and then. Today I want to write down how to notice them from the outside.

Start from the premise that "success" and "result" are different

We tend to treat the exit code as proof of a result. But exit 0 only guarantees that the last command returned no error. There are plenty of paths where the job finds nothing to generate and exits cleanly without creating anything.

In my case, the cause was usually one of these. A reference-data cat hit the wrong path and returned empty, so the job slid past topic selection in silence. The disk was full and a clone gave up halfway, yet the following steps still went through the motions. A model pause left generation empty-handed, with nothing to push. None of these are individual bugs; they share the same structure — a no-op that still counts as success.

So the goal of monitoring is not "did the job crash." It is "did the expected output actually come into existence." Narrowing to that one question makes the design much cleaner.

Why you cannot trust the job's own log

The first thing you want to reach for is writing a "done" line at the end of the job. I did exactly that. It does not work.

Silent no-ops happen precisely when the run takes a path off the main flow. And the "write the done log" step sits at the tail of that main flow. In other words, the situation that drops your log and the situation that drops your output share the same root. The one time it fails is the one time the line announcing failure never gets written. Self-reporting goes quiet at exactly the moment you need it most.

That realization became the starting point for the design. Move the observer outside the job. Base the verdict not on what the job says about itself, but on facts a third party — independent of the job — can see. Once you decide that, what to record becomes obvious.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN
✦Why a job's self-reported log cannot be trusted, and how to record a heartbeat to a JSONL ledger
✦The dead-man's-switch idea — absence as the signal — and the expected ⊆ observed reconciliation
✦A full watchdog that double-checks output against git ground truth instead of self-reports
Secure payment via Stripe · Cancel anytime
✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

or
Unlock all articles with Membership →
Share

Thank You for Reading

Claude Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • ✦Copy-paste ready implementation code
  • ✦New advanced guides published daily
  • ✦$5/mo or $15 for lifetime access
View Membership →

Related Articles

⟐ Claude Code2026-08-31
Half of My Scheduled Runs Vanished Without a Single Error
A batch job set to run twice a day was only firing once. No errors, no failure alerts. Here is how to expand your own schedule, count expected runs, and reconcile them against execution records to catch silent misses.
⟐ Claude Code2026-07-07
I Could Detect Failures — Then the Alerts Grew So Loud I Stopped Noticing
The moment I could detect silent job failures, my phone started buzzing too often to be useful. Here is how I collapsed alerts by action rather than event, added hysteresis and quiet hours, and built a three-step escalation so only the pages worth waking me survive.
⟐ Claude Code2026-09-02
Two hooks that record every model switch and stop the ones you never agreed to
Build a PostModelSwitch hook that logs every model change and a PreModelSwitch hook that blocks unapproved switches during unattended runs. Complete scripts, measured timings, and the reason the two jobs must stay separate.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links