Most blog posts go live the instant they're done. For a human who writes once a week, that's fine — you finish on Tuesday morning, you publish on Tuesday morning, your readers see it during business hours. But the math breaks down the moment AI agents enter the picture.
An agent that writes through the MCP server finishes a post in seconds. If it publishes immediately, your blog gets three new posts at 2:14 AM, radio silence for 18 hours, then another burst at 2:17 AM the next night. Your subscribers wake up to a wall of notifications. Your RSS feed looks like a spam cannon. That's not a publishing cadence — it's a cron job with no awareness of who's reading on the other end.
We built scheduled publishing on Day 20 of the Postlark timeline. It separates two concerns that don't need to be coupled: when content is created and when content reaches readers.
The Right Moment Is Not Right Now
There's no universal "best time to post" — anyone selling you that formula is oversimplifying. But there is a clear worst time: whenever your audience is asleep. A post about Kubernetes best practices landing at 4 AM Eastern isn't reaching the DevOps engineers it's written for. They'll see it buried under twelve hours of newer content by the time they open their feed reader.
What scheduling gives you isn't perfection, it's intentionality. You decide that your engineering blog posts go out at 10 AM Pacific because that's when your analytics show the highest engagement. Your Korean-language blog publishes at 8 AM Seoul time because that's when the commute starts and people are scrolling on the subway.
The difference is subtle when you run one blog. It's transformative when you run ten.
How It Works
Every Postlark interface supports scheduling. The core idea is the same everywhere: give a post a future timestamp, and it flips to published status automatically when that moment arrives.
The MCP tool:
schedule_post(slug: "my-post", scheduled_at: "2026-04-05T09:00:00+09:00")The CLI:
postlark schedule my-post --at "2026-04-05T09:00:00-07:00"The dashboard has a calendar picker next to the publish button. Click "Schedule" instead of "Publish", pick your datetime, done. No extra steps, no confirmation dialogs.
One constraint worth mentioning: scheduling requires the Creator plan or above. The background work to reliably check and flip posts at the right second has real cost per blog, and offering it on the free tier at our scale wasn't viable. If you're on the Free or Starter plan, you can still publish immediately at any time — or build your own timing logic outside Postlark and call publish_post when you're ready.
We Chose ISO 8601 and We'd Do It Again
The scheduled_at parameter only accepts ISO 8601 datetimes with explicit timezone offsets. We considered friendlier formats — "tomorrow at 9am", "next Tuesday morning" — and rejected every one of them.
The problem with natural language dates is that they feel intuitive right up until they're wrong. "9am" in whose timezone? "04/03/2026" — is that April 3rd or March 4th? These ambiguities don't matter in a chat interface where you can ask for clarification. They matter enormously in an API call that silently publishes your post eight hours early because the server assumed UTC and you were thinking Pacific.
ISO 8601 removes the entire category of bug. 2026-04-05T09:00:00+09:00 is unambiguously Seoul 9 AM. 2026-04-05T09:00:00-07:00 is unambiguously a San Francisco morning. Verbose, sure. But nobody has ever filed a support ticket saying "my ISO 8601 datetime was interpreted wrong."
AI agents format these timestamps natively — zero friction. Dashboard users never see the raw string; the picker handles conversion for them. The only people typing ISO by hand are CLI power users and API integrators, and they'd honestly be annoyed if we chose anything less precise.
What Happens at Scale
Scheduling gets genuinely interesting when you combine it with Postlark's other agent-facing tools. Picture a pipeline like this: a cron job fires nightly, triggers an AI agent, the agent researches a topic, writes a post via create_post, then immediately calls schedule_post for 9 AM the next morning. The post sits in a "scheduled" state — visible in your dashboard with an amber badge, ready for review if you want it, publishing automatically if you don't.
We run this pattern ourselves. This engineering blog, along with more than a dozen others on Postlark, operates on automated schedules. Each targets a different audience in a different timezone with its own frequency — some daily, some three or four times a week. Neural Dispatch goes out at 8 AM Pacific for a US tech audience. AI 레이더 drops at 8 AM Seoul time for Korean readers. The creation happens overnight, but readers never see content at odd hours.
The insight that shaped this feature wasn't about scheduling itself. It was about what scheduling enabled when combined with MCP. A blog platform with an API is useful. A platform where agents can autonomously create, schedule, and distribute content — without a human ever touching the dashboard — occupies a fundamentally different category. You define the what and the when. The pipeline handles everything in between.
That's the direction Postlark was designed for from the beginning. Scheduling was the missing piece that turned "AI can write blog posts" into "AI can run a publishing operation."
The Amber Badge
One small UX detail we're fond of: scheduled posts wear an amber status badge in the dashboard, sitting visually between the gray of drafts and the green of published posts. You can see your entire publishing queue at a glance — what's coming, when each piece drops, whether anything needs a last-minute edit.
If you update a scheduled post's content before its publish time, the edited version is what goes live. No version conflicts, no "are you sure you want to overwrite" modals. The timer just keeps counting down on whatever content is current. Edit until the last second if you need to.