How Many Blog Posts Per Day: 10 Scheduled, 5.6 Shipped

Since July 29 this Mac mini has fired a publishing slot ten times a day, and each slot is supposed to research, write and ship one post. Thirty-seven days later the ledger reads 370 slots scheduled, 208 posts published. That is 5.6 posts a day against a target of seven, a 56% fill rate, and it is the number I would give anyone asking how many blog posts per day an unattended AI pipeline actually produces. The usual answer to that question is an opinion about what Google rewards. This one comes from a log file, and most of the missing 162 slots have nothing to do with writing.

What a slot is

A launchd job runs claude -p with a fixed prompt at 07:30, 09:00, 10:30, 12:00, 13:30, 15:00, 16:30, 18:00, 19:30 and 21:00 KST. The prompt counts today's entries in the publishing log, stops at ten, and otherwise picks one topic, researches it, writes the post, inserts it into the database, deploys the site and records what it did. One unit of work per run, so a crash leaves nothing half-published. The guardrails are in the unattended schedule post. What matters here is the shell wrapper around it, which appends one line after every run:

[2026-09-03 19:41] daily-content run finished (exit 0)

That line, 319 times, is the whole dataset. The wrapper does not log when a run starts, so I reconstructed durations by subtracting the slot's grid time from its finish time. That is only valid because no run outlived the 90-minute gap to the next slot: median run 26 minutes, the middle half between 20 and 34, the longest 76. Ten slots at 26 minutes is about 4.3 hours of model time a day when everything works.

The ledger, day by day

9 days hit the ceiling of ten. 20 days reached the seven-post target. Ten days published nothing, and those ten days are 100 of the 162 missing slots. Take the zero days out and the pipeline averages 7.7 posts a day, which is roughly what the prompt asks for. The weekly totals show the same shape: 55 and 57 posts in the two good full weeks, then 23 and 28 in the two bad ones. The writing pace was never the constraint. Whole days disappearing was.

Where 162 slots went

Of 370 scheduled slots, 319 wrote a finish line. 205 exited 0, 113 exited 1, one exited 139. The exit-1 runs almost all printed a single line and died within seconds, so I bucketed them by that line. The 51 slots with no finish line split into 37 on days the disk was locked and 14 I cannot explain.

The buckets add to 165 failed slots against a gap of 162, because three of the 205 clean runs shipped two posts each and I have not audited which. Three causes cover 138 of the 162: the account's token, the account's weekly cap, and a disk that stayed locked after a reboot. None of them is a content problem. I also grepped the log for the phrases the prompt tells a run to use when it gives up on a topic and found none. A run that surrendered in other words would slip past that grep, so the honest figure is "none I can find" rather than zero.

The token, 56 slots

The biggest single cause. On August 21, 22, 23 and 26 all ten slots printed Failed to authenticate: OAuth session expired and could not be refreshed and exited 1, and August 5, 6, 20, 24 and 27 lost 16 more between them. A headless process cannot open a browser to log back in, and the alert that should have told someone lived inside the process that was dying. I wrote up the expiry itself and, separately, why 34 dead slots produced zero alerts. The recovery both times was a person logging in. I do not have an unattended fix for this one.

The weekly cap, 45 slots

The subscription's weekly usage limit. It first hit on Saturday August 1, and twenty consecutive slots printed resets Aug 3 at 6pm before the weekend was over. It took all of August 19 the same way, and a few slots at a time on Aug 3, Aug 5, Aug 10–11, Aug 13, Aug 18–20. This machine shares its meter with three other projects, so the pipeline's own consumption is not the whole story, and I cannot separate the shares from this log. The first weekend is written up on its own; the lesson there was that the peripheral jobs raised the alarm and the main one did not.

The locked disk, 37 slots

At 21:26 on August 28 the machine rebooted on its own. FileVault kept the data volume sealed until a password was typed at the console at 17:35 on September 1. launchd never ran the slots, so there is no exit line: the 37 slots simply do not exist in the log. That is the difference between this cause and the first two. A refusal writes a line, a locked disk writes nothing, and my monitoring watched for lines. The unlock path that would have saved three days is in the Tahoe SSH unlock post.

The small ones

Six five-hour session refusals, four of them at 15:00 or 16:30, the last two slots before the 17:30 reset, and two on the evening of August 11; the reset grid explains why those two slots and not others. Five refusals naming the model rather than the account. One API Error: 529 Overloaded. One exit 139 on August 8, a segmentation fault, with nothing in the log above it. And 14 slots with no finish line on days the machine was up, which the wrapper gives me no way to investigate, since it only writes at the end. Logging the start is the first change I am making after this post; the issue tracker has plenty of the refusal strings above but nothing for a run that vanishes.

Which slots produce

The ten slots are not equal. Posts by slot over the 37 days: 07:30 18 · 09:00 19 · 10:30 19 · 12:00 21 · 13:30 24 · 15:00 21 · 16:30 21 · 18:00 25 · 19:30 20 · 21:00 20. The 18:00 slot leads because it starts thirty minutes after the session reset with a full budget. The 15:00 and 16:30 slots took four of the six session refusals. The morning slots trail because an overnight token expiry or weekly cap eats the morning first: the 07:30 run discovers it, and on the three days a fix landed the same day (August 20, 24 and 27) it landed after two, four and six slots had already died.

How many should you schedule

If the question is how many blog posts per day an AI can write, my log says ten, on nine separate days, with no sign of the model running out of topics. If the question is how many you will actually publish, multiply what you schedule by a survival rate, and the survival rate is set by the things that kill whole days: credentials, quotas and the machine itself, not the writer. Mine was 56% over five weeks, and I would have guessed 85% before counting. Three things would have moved it. Log the start of every run, not just the end. Put the alert outside the process it is watching. And treat a reboot as a scheduled event with fdesetup authrestart, because an unplanned one on a FileVault disk costs days, not minutes. What the surviving 208 posts cost in dollars is in the cost post.

The wrapper, the idempotency gate and the checklists each run follows are in the Playbook, which is my own product. Disclosure: I earn from Playbook sales, and product links elsewhere on this site are Amazon affiliate links that pay a commission at no cost to you.

FAQ

How many blog posts per day can an AI agent publish unattended?

In my log, ten scheduled slots produced a mean of 5.6 posts a day over 37 days, 7.7 on days without an account or machine failure, and the ceiling of ten on 9 days. The writing side never ran dry; the losses were credentials, quotas and a locked disk.

Why do scheduled Claude Code runs fail?

Across 370 slots, the top causes were an expired OAuth token that headless mode cannot refresh (56 slots), the weekly usage limit (45) and a FileVault-locked disk after an unplanned reboot (37). Session limits, model limits, a 529 and a segfault made up 13 more.

How long does one automated blog post take end to end?

Median 26 minutes from slot start to process exit, with the middle half between 20 and 34 minutes and a maximum of 76. That covers topic selection, web research, writing, database insert, deploy and URL verification for one post.

Update, 2026-09-05: the 26-minute figure above was inferred from the launchd grid. I have since timed 167 runs from their session transcripts: median 26.4 minutes, maximum 66.6 rather than 76, and the writing itself is a four-minute slice of that.

Sources and method: every count above comes from ops/schedule/content.log on this machine, parsed on September 3, 2026 for the 319 lines matching daily-content run finished (exit N) between July 29 and September 3, with each exit line attributed to the output immediately above it and short outputs bucketed by their first 120 characters. Post counts come from the site database, with timestamps converted from UTC to Korea Standard Time before bucketing by day. Durations are inferred from the slot grid, not logged, and are valid only because no run exceeded 90 minutes. The 14 unexplained slots and the three double-post runs are reported as unknowns rather than guessed at.