Why I Publish on Weekdays, Forever

The most common advice about how often to blog is "as often as possible." It's terrible advice, because "as often as possible" is a burst — a heroic week of ten posts, then silence for three months when real work gets busy, then guilt, then a restart. Search engines don't reward bursts. They reward a site that keeps showing up. The question isn't how often you can publish. It's how often you can publish forever, without heroics, without depending on anyone remembering to. This very post is proof the answer exists, because it shipped on the exact system I'm about to describe, with nobody awake to press publish.

Sustainable beats maximum

Cadence is a promise to the crawler. A site that adds a page most weekdays tells search engines it's alive, maintained, and worth checking often. A site that dumps twenty posts in March and nothing after tells them the opposite — that whatever's here is finished and probably stale. The steady trickle wins, and not by a little. So the real design goal is a pace you'll actually keep for years, which for me is weekdays: often enough to signal life, rare enough on weekends to be honest that the machine, not a person, is doing the work.

The catch is that any cadence dependent on human willpower dies. It has to run on automation, or it isn't sustainable — it's just a chore you'll eventually skip.

The three pieces: date gate, daily rebuild, loud failure

Here's the architecture I run, and it's only three parts.

The date gate. Every post carries a publish date in its frontmatter. The site is built to hide any post dated in the future — they exist in the repository, fully written, but the public site filters them out until their date arrives. This means the writing and the publishing are decoupled. I can write eighteen posts in an afternoon, date them across two months of weekdays, and each one appears on its own day without another keystroke. The backlog is the schedule. (It's also why the sitemap has to derive its dates from real source history, not from new Date() — a truthful publish schedule deserves a truthful lastmod.)

The daily rebuild. A future-dated post won't appear until the site rebuilds after its date passes. So something has to trigger a rebuild every weekday morning. In this repo that's a small scheduled workflow that pushes a one-line "pulse" commit each weekday, which makes the host rebuild production, at which point the date gate releases whatever's newly due. Crucially, the pulse checks whether today's date is already stamped rather than trusting the clock — scheduled crons are best-effort and get delayed or dropped, so the trigger keys on "is today done yet?", and redundant runs simply no-op. That idempotency is what makes it reliable instead of merely scheduled.

The loud failure. The part everyone forgets. A quiet automation that fails quietly is worse than no automation, because you think you're publishing while the site sits frozen for a month. So a verify step checks that the day's publish actually happened and raises a loud alert — a message straight to my phone — if it didn't. The system is designed to fail loudly, because silent success and silent failure look identical until you check, and I'm not going to check every day. That's the whole point.

Three pieces: write ahead and date-gate, rebuild daily on an idempotent trigger, and alert loudly on failure. It publishes on weekdays whether or not I'm at a keyboard, whether or not I remember, whether or not I'm on a job. It's the same engine, tuned per site, behind every drip in the fleet — and the reason cadence is a solved problem for me instead of a recurring guilt.

Sustainable, automated, loud when it breaks. That's why I publish on weekdays, forever — and why "forever" is a claim I can actually make.

Want a content engine that runs itself and yells when it doesn't? Inquire about a project →