What I Run as Cron Jobs in My Claude Stack: 6 Automations

My studio publishes daily and I do not touch most of it. Six cron jobs run the whole pipeline on a server that costs 2 EUR a month. Here is the actual table, what each job does, and the mistakes I made building it.

The publish job that started everything

The first cron job I wrote was the auto-publish step. It runs at 08:30 every morning. It picks the next article from a queue folder, validates it against my rules (word count, banned phrases, link minimums), and pushes it live if it passes.

The validation is the important part. Before I had it, I published a post with three em dashes and a broken internal link. Nobody told me for two days. Now the job refuses to publish anything that fails a check, and it writes the failure reason to a log I read with coffee. In four months it has blocked 11 posts. Each one would have been a small public embarrassment.

The job itself is short. It is a shell script wrapped around a Claude call that does the final read-through, plus a few grep checks for the hard rules. The grep checks are dumb and fast. The Claude read is slower but catches things grep cannot, like a paragraph that contradicts the headline or a CTA that sounds desperate.

I keep the queue as plain markdown files numbered by date. The job sorts by filename and takes the oldest unpublished one. If the queue is empty, it does nothing and logs "queue empty." That last line matters more than it sounds. A cron job that fails silently is worse than no cron job, because you stop trusting your own logs.

The timing also matters. 08:30 is before most of my readers are awake but after the index rebuild (more on that below) has finished. Cron jobs in a stack have an order, even when they run at different times. Get the order wrong and you publish a post that links to an index that does not know the post exists yet.

If you want the full architecture this sits inside, Claude Blueprint walks through how the pieces connect. The publish job is the heartbeat, but it is useless without the five others feeding it.

Auto-syndicate to four channels

At 09:00, thirty minutes after a post goes live, the syndicate job fires. It takes the freshly published article, generates platform-specific versions, and pushes them out to four channels.

Each channel gets a different shape. The long-form network gets the first three paragraphs plus a link. The short social channels get a single hook line and the link. The email list gets a plain-text summary with the TLDR items broken into bullets. One source, four outputs, zero copy-paste.

The version generation is a Claude prompt with the article as input and a template per channel. I learned to keep the templates strict. Early on I let Claude "adapt to the platform," which meant it invented hashtags I did not want and added emoji to a channel where my audience hates emoji. Now each template says exactly what to produce and what to never include. Creative freedom in a syndication job is a bug, not a feature.

For the actual scheduling I push some of these through Buffer so they land at sensible local times instead of all at 09:01. The cron job hands the content to the scheduler and lets the scheduler handle the clock. Splitting "what to post" from "when to post" made the whole thing more reliable. The cron job has one job. The scheduler has one job. Neither tries to be clever about the other.

I tracked the time this saves. Manual syndication of one post across four channels took me about 25 minutes when I did it by hand, mostly because I would get distracted reading replies. Across roughly 90 posts that is over 37 hours I did not spend reformatting the same words four times. The syndicate job also never gets distracted, never forgets a channel, and never posts the wrong link because it was rushing.

The failure mode here is a channel API going down. When that happens the job logs the failure per channel and continues with the others. One dead channel does not kill the whole run. That isolation took me an afternoon to build and has paid for itself a dozen times.

Auto-pull and the blog-index rebuild

Two jobs keep my content honest. The first is auto-pull, which runs at 06:00. It syncs my content repo, pulls any edits I made from my laptop the night before, and stages them for the day. I write in markdown files and sometimes fix typos at midnight. The pull job means those fixes are live before the index rebuild touches anything.

The second is the blog-index rebuild, and it runs every six hours. This is the job I underestimated most. The index is the page that lists every article, the cluster pages, the tag groupings, and the "related posts" blocks at the bottom of each article. All of that is generated, not hand-written.

When I publish a new post, dozens of existing pages should now link to it. The cluster page needs the new entry. The tag pages need it. Older articles in the same cluster should surface it in their related blocks. Doing that by hand is impossible at any real volume. So the rebuild job walks every article, reads its tags and cluster, and regenerates all the cross-links from scratch.

Regenerating from scratch every time sounds wasteful. It is, slightly. The whole rebuild takes about 40 seconds. But the alternative, trying to incrementally patch the index, was a source of bugs I could not trace. A full rebuild is boring and correct. I will take boring and correct over clever and broken every single time.

Running it every six hours instead of once a day means a post published at noon does not wait until tomorrow to appear in related blocks. Four rebuilds a day, each catching whatever changed since the last. The cron schedule is `0 /6 ` and I have not touched it since I set it.

The rebuild also writes a count to its log: how many articles, how many links generated, how many clusters. When that count drops unexpectedly, I know something deleted content it should not have. It is a cheap canary. I learned to log counts on every job that touches many files. Background: the index rebuild also feeds the garden-walk job below, which is why their timing is staggered.

Garden-walk and the /now-page refresh

The last two jobs are the quiet ones nobody notices until they break.

Garden-walk runs at 03:00, when nobody is reading. It crawls every published article and checks every link. Internal links get verified against the actual file structure. Outbound links get a HEAD request to confirm they still resolve. Anything broken goes into a report I get each morning.

This job has saved me real embarrassment. An affiliate URL changed format and 14 of my older posts suddenly pointed at a dead page. Garden-walk caught it the next morning. I fixed the template, the index rebuild propagated the fix, and most readers never saw the broken version. Without the crawl I would have found out from an annoyed email weeks later, or worse, never found out at all.

Garden-walk does not auto-fix anything. I made that choice deliberately. A job that edits live content while you sleep is a job that will eventually edit something it should not. It reports, I decide. The few minutes I spend reading its report each morning are worth more than the risk of an automated fix going wrong on 90 articles at once.

The /now-page refresh is the smallest job and my favorite. My /now page says what I am working on this week. It runs every morning at 07:00 and pulls from a single status file plus the last three published articles. So the page always reflects what actually shipped, not what I intended to ship in some hopeful planning session.

It is a tiny touch. But a /now page that is three weeks stale tells a visitor the studio is dead. A /now page that updated this morning tells them someone is home. The refresh job keeps that signal honest with zero effort from me. It reads the status file, formats the recent posts, and writes the page. Eight seconds, every day.

Together these six jobs mean the studio runs whether I am at my desk or not. I have published from a train, from a phone with a one-line commit, and once accidentally while asleep because I had queued three posts ahead. The cron table does not care where I am. That is the entire point of building it this way.

Bottom Line

Six cron jobs, one cheap server, and a daily publishing studio that mostly runs itself. The pattern across all of them is the same: each job does one thing, logs a count or a status, and fails loudly instead of silently. Publish at 08:30. Syndicate at 09:00. Pull at 06:00. Rebuild the index every six hours. Walk the garden at 03:00. Refresh /now at 07:00.

None of this is complicated. The hard part was deciding what to automate and what to keep manual. I automate anything boring and verifiable. I keep manual anything that edits live content based on judgment. That line is the whole philosophy.

If you are building your own version, start with the publish job and add the others as the pain shows up. You do not need all six on day one. You need one job you trust, then a second. The full picture lives in Claude Blueprint if you want to see how the pieces fit before you start wiring your own.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)