The article you are reading put itself on the schedule.
A Tuesday night, a little after seven, a program woke up on my desktop. It worked out which slot came next, took a topic off a list I keep, wrote a draft, checked its own facts against the web, turned the whole thing into the exact HTML this site expects, and parked it in WordPress set to go live Wednesday at nine in the morning. I did not open a browser. I did not touch a key. I found out it had worked the way I find out anything worked around here. I read a log.
Let me walk you through what actually runs, because most of it is boring, and boring is the whole point. The systems that carry weight are almost never clever. They are patient, and they are stubborn, and they do the same small thing at the same time every day whether you are watching or not.
The thing that writes
There is a folder in my repo called article-autopilot. Inside it is an instruction file and a handful of scripts, and on Sunday, Tuesday, and Thursday evenings, Windows Task Scheduler runs one line. That line launches a headless Claude Code session. No window, no chat, nobody to talk to. Just the model, my instruction file, and my whole project sitting there on disk.
It reads a topic queue, a plain markdown file where I stack up what I want to write and in what order. It takes the top one that has not been used yet for that day of the week. It researches, because I made that a hard rule in the instructions, no numbers without a source it opened that same run. It writes in my voice, or as close to my voice as I have managed to teach it, using a calibration file I keep tuning every time it drifts and starts sounding like a press release. Then it converts the article into the markup this theme wants, wraps it, and hands it off.
I want to be plain about what this is. It is a cron job with a writer bolted on. That is all. It is not thinking about my brand while I sleep. It is a scheduled task, and scheduled tasks are the most boring thing in computing, and that is exactly why I trust them.
The thing that publishes
Here is a thing almost nobody tells you about WordPress until it bites you. WordPress cron is a lie. It does not run on a clock. It runs when somebody visits your site. No visitor, no cron, and your carefully scheduled nine-a.m. post just sits there in the dark, marked scheduled, waiting for a stranger to wander by and trip the wire.
At the traffic this site pulls, that could be hours. A post I set for nine could publish at noon, whenever the first real human of the day happened to load a page.
So there is a second task. Every Mon, Wed, Fri at 9:05, a script opens the live homepage in a real browser and lets it load, once. That single visit wakes cron, cron sees the post is due, cron publishes it. Why a whole browser to load one page? Because Cloudflare sits in front of this site and challenges plain command-line requests, so a bare little curl gets a locked door. A real browser profile walks through. It is a five-second visit that exists for no reason except to be the footstep the site needs to hear.
Update, the morning this published: that footstep is retired. Last night a real server cron went in, the boring kind, a one-line job on the host that pokes the site every five minutes whether anyone visits or not. The browser trick worked for months, but it was a crutch pretending to be a leg. This is the leg.
The things that fire the second it goes live
The moment that post flips from scheduled to published, a few things move at once, and none of them need me.
WordPress fires an internal signal on the status change. A dispatcher I wrote listens for it, and when the thing that published is an article, it does two jobs. It hands the article to the newsletter queue, which as of this week means a Monday digest, one email carrying everything the site published the week before instead of a separate blast for every post. And it pings IndexNow.
IndexNow is the one worth knowing about if you run anything that publishes. Normally you put up a page and then you wait, sometimes days, for a search engine to crawl around and notice you exist. IndexNow flips it. You tell them. My site pushes the new URL straight to Bing, Yandex, Seznam, and a couple of smaller engines, and they know inside minutes instead of whenever their crawler felt like it. Submit it to one and they share it with the rest, that is the whole idea of the protocol. DuckDuckGo pulls its results from Bing, so it gets the news too, secondhand. The ping is non-blocking, so it never makes the reader wait on the page. It just goes out the side door. Google does not use IndexNow, so Google is a separate conversation, handled through Search Console, and no, I have not fully won that one either.
The part that still sits dark
I hate tutorials that sell you the clean version of a messy thing, so let me show you the mess.
The social posting is wired and it does nothing. The dispatcher queues every new article for the social manager, which knows how to talk to a whole shelf of platforms. But it needs API keys I have not connected yet, so right now it is a conveyor belt running with nothing on it. Content rolls off the end into an empty room. The plumbing is real. The water is not on.
IndexNow pings out fine every single time, but here is the catch: the payoff is gated on something outside my code. Cloudflare, through my host, has been challenging Bingbot, which means Bing hears me shout the URL and then still cannot walk in to read it. I am announcing a door that is bolted. The fix is one setting in a dashboard I have to log into, and it has been on my list.
And the writer? Last Monday it wrote a good piece, a real one, and staged exactly nothing. A browser profile was locked by some orphaned process, and behind that the WordPress login had quietly expired, and the retry loop tried sixty-four times through the night and got told sixty-four times that the session was dead. The post never went out. The machine did all its work and then drowned an inch from the surface, because the one human credential it depends on had gone stale and nobody was awake to notice.
That is the honest shape of automation. It is only ever as awake as the login underneath it.
Why it is built this stupid, simple way
None of this is a product. There is no SaaS in the stack, no dashboard I pay for, no service holding my content hostage. It is Windows Task Scheduler, a browser profile, WordPress’s own cron, a search-engine ping, and a few hundred lines of glue I wrote in the same terminal I write everything else in. Every single piece was already sitting on the machine or already in the platform. I just got them talking.
You could build most of this in an afternoon. The writer is the fancy part and even the writer is just a scheduled task pointed at a model with a good instruction file. Everything else is the boring, patient infrastructure that has run the web for twenty years. A clock. A visit. A signal. A ping.
I check the log most mornings with my coffee. Some mornings it says a post is staged and waiting and I go read it and change a word. Some mornings it says the profile was locked and nothing happened, and I sigh, and I log back in, and the whole thing starts breathing again on its own the next run.
Forward → Upward ↑ Onward ↗︎
Mstimaj
Join the Conversation
Share your thoughts and connect with other readers