CASE · Major · monitoring-gap
VerifiedFirsthand recordOur "new issue every Friday" didn't ship. Every automated step ran; the drafting step had nothing to start it
This site promises a new issue every Friday. On Friday, October 16, 2026, issue 3 (2026-W42) did not come out. Collection and scoring had succeeded every day and triage was done, but there was no draft branch and no pull request. Nothing raised a flag until the operator felt on Monday, October 19, that the article count had stopped growing, and looked.
4 min read
- OBSERVED
- CATEGORY
- monitoring-gap
- BLAST RADIUS
- reputation, uptime
- DETECTED BY
- manual-observation
- TAGS
- #weekly-issue #editorial-pipeline #github-actions #human-in-the-loop #missing-trigger #silent-failure #dogfooding
CH 1
Cause
Of the week's steps, only Wednesday's "Claude writes the drafts" had nothing to start it. The design doc listed the day and who does it, but in practice the step ran only when the operator opened a session and asked. That week the operator was busy with SEO fixes and launching another product, so no one asked. The later steps, fact-checking and publishing, fire when a pull request exists, so nothing reacted to one not existing.
CH 2
Consequence
The Friday issue was more than three days late, breaking the published update promise. The last new article on the site was from October 12, and nothing new went up for a week after that. The 10 full entries, 24 briefs and 4 debates selected in triage sat undrafted. No data was lost.
CH 3
Fix
On October 19 the late issue was drafted and opened as a pull request (3 entries, 5 briefs, 1 debate). Prevention is still being decided, with two options: start the drafting step at a fixed time, and alert when Friday passes with no issue published. Steps handed to a person or an AI get a starter and a watcher for "it didn't happen", like every other step.
LOGTimeline
- OCCURRED
Date of record (date_observed)
- DETECTED
3 days after it occurred · Detected by:
manual-observation
Built only from the dates on record (date_observed, date_detected, date_resolved).
What happened
Blackbox Blast promises a new issue every Friday. On Friday, October 16, 2026, that week's issue (issue 3, 2026-W42) did not come out. Issue 1 had been drafted on September 30, and issue 2 was drafted on the evening of Friday, October 9 and published the same day.
Only one step stopped. Daily collection and scoring kept succeeding in GitHub Actions, and the week had gathered 52 candidates. The operator had triaged 46 of them in the admin screen, picking 10 full entries, 24 briefs and 4 debates. But no draft branch and no pull request were ever created to turn them into articles.
It was noticed on Monday, October 19, when the operator felt the article count had stopped growing and looked into it. No system said anything before that.
The chaos on the ground
Every automated step turned out to be healthy. Collection succeeded every day from October 12 to 19, and writing triage decisions back into the candidate list succeeded after every decision. The fact-check, author-outreach drafting and search-engine notification workflows all ran. There was no failure in any log.
The design doc lays out the week like this. Every day, collect and score. Tuesday, the operator triages. Wednesday, Claude writes the drafts and opens a pull request. Thursday, the operator reads the automated fact-check results. Friday, the operator merges and the issue goes live.
Wednesday was the only step with nothing to run it. Both earlier issues were drafted when the operator opened a session and asked for drafts. That week the operator was busy with SEO fixes (six pull requests) and launching the introduction page for another product. The moment to ask for drafts never came.
Triage had also slipped. The design calls for 15 minutes on Tuesday, but W42 was triaged bit by bit from October 12 to 18 and finished on Sunday, after Friday had passed.
Root cause
In the design doc, "Wednesday: Claude drafts" sat in the same format as every other line. Behind the collection line is a daily cron job; behind the fact-check line is a workflow triggered by pull requests. Behind the drafting line there was nothing. It named a day and an owner, but not what starts it. A step owned by an AI does not begin until a person asks.
The second cause is how the later steps are triggered. Fact-checking runs when a pull request is opened, and publishing runs on merge. Each fires when something happens; none reacts when something fails to happen. With no draft, there was no fact-check and no publish, and Friday went by in silence.
There was even a session on October 18 reviewing the past two weeks of operations. As far as a search of the session records shows, the missing issue did not come up.
The fix
On October 19 the late issue was drafted. From the triaged items it was narrowed to 3 full entries, 5 briefs and 1 debate, written in Japanese and English, and opened as a pull request. At the time of writing, the automated fact-check results were still being reviewed, and the issue was not yet published.
Prevention is still being decided, with two options. One is to start the drafting step at a fixed time on Wednesday. Drafting involves a lot of judgment, so it would not be fully automated: only starting the work and opening the pull request would be. The other is to alert when Friday passes with no issue merged. If the first fails, the second catches it.
Lesson for operators: writing a day and an owner into a schedule does not make a step run. Steps handed to a person or an AI need a starter, just like cron steps. And alongside triggers that react to what happened, keep a watcher for what should have happened and didn't. A failure that occurs while everything is succeeding never shows up in a log.
Sources
- Firsthand account from the site operator. There is no public write-up to link to.
Pass this record on to your team