How to Automate Publishing
Automated publishing is not just “send content when the time arrives.”
Without workflow control, it can go wrong quickly: drafts get published by mistake, images fail to upload, links are broken, content is duplicated, scheduled jobs fail silently, one channel succeeds while another fails, or content goes live before review.
The core of automated publishing is turning the path from draft to published into a controlled pipeline.
This article references official materials:
- Vercel Cron Jobs
- Vercel Managing Cron Jobs
- GitHub Actions schedule event
- WordPress REST API Handbook
What Should Be Automated
Not all content should be automatically published.
Good candidates:
Scheduled blog posts
Product changelogs
Weekly newsletters
Social content distribution
RSS updates
Multilingual article publishing
Documentation update notices
Tool directory update notices
Poor candidates for full automation:
High-risk opinion pieces
Legal, medical, or financial advice
Major product announcements
Pages involving pricing or promises
Unreviewed AI content
Long posts requiring manual layout
Start automation with low-risk, structured, reversible content.
Content State Machine
The first step is a content state machine.
A basic one:
draft
reviewing
approved
scheduled
publishing
published
failed
archived
Do not rely only on published=true.
Clear states make the next action obvious.
For example:
draft: still being edited
reviewing: waiting for review
approved: approved but not scheduled
scheduled: publish time is set
publishing: currently publishing
published: live
failed: publishing failed and needs attention
archived: removed or archived
Pre-Publish Checks
Automated publishing needs checks before publishing.
Check:
Title exists
Body exists
Cover image exists
slug is unique
Publish time is valid
Author exists
Category exists
Internal links work
External links are reachable
Image alt text exists
SEO title and description exist
Status is approved or scheduled
If a critical check fails, do not publish.
The first rule of automation is not “publish as much as possible.” It is “block publication when something is wrong.”
Running Scheduled Jobs
Automated publishing is usually triggered by a scheduled job.
Common options:
Vercel Cron Jobs
GitHub Actions schedule
Server crontab
Cloudflare Workers Cron Triggers
Delayed jobs in a queue
Background worker polling
Vercel Cron Jobs documentation explains that cron expressions can trigger Vercel Functions. GitHub Actions schedule events support POSIX cron syntax for running workflows on a schedule.
Pay attention to:
Time zones
Duplicate execution
Many schedulers use UTC. Convert clearly between product time, Beijing time, New York time, and user local time.
Duplicate execution is common. Publishing jobs must be idempotent.
Publishing Must Be Idempotent
Idempotent means the same job can run multiple times without duplicate publishing or broken state.
Automated publishing must prevent:
Same article published twice
Same channel pushed twice
Retry after timeout creates duplicates
Two workers claim the same article
Publishing succeeds but status is not updated
Common techniques:
Add publish_job_id to each article
Lock the record before publishing
Store channel publish records separately
Use a unique external_id per channel
Update status in a transaction
Check whether already published before running
Idempotency matters more than exact timing. A missed job can be retried. Duplicate publishing is harder to clean up.
Track Channels Separately
One piece of content may publish to many places:
Website
RSS
WeChat Official Account
Email
X
LinkedIn
Telegram
Discord
Knowledge community
Do not use one status to represent all channels.
Use channel publish records:
content_id
channel
status
scheduled_at
published_at
external_id
url
error_message
retry_count
If the website succeeds but email fails, you can retry email only instead of republishing everything.
Process Images and Attachments First
Many automated publishing failures come from images, not text.
Before publishing, confirm:
Cover image is generated
Image paths are valid
Images are uploaded to the target channel
Format and size match channel requirements
Alt text exists
Remote image URL is reachable
Unsupported formats are converted
If a channel requires media upload before adding media_id to the post, treat media upload as a separate step.
Do not process images at the last second.
Retry and Alert on Failures
Automated publishing will fail.
Common causes:
Third-party API timeout
Expired token
Image upload failure
Unsupported content format
Network issue
Channel API rate limit
Scheduled job did not trigger
On failure:
Record the error
Mark failed
Retry by rule
Alert after retry limit
Keep a manual retry button
Do not swallow exceptions
Vercel's cron management documentation also describes viewing cron invocation logs and securing cron endpoints with CRON_SECRET.
Keep a Human Gate
The safest pattern is: AI and automation generate and schedule content, but humans confirm final publishing when risk is high.
Especially for:
First publish to a new channel
Large batches
Pricing and promises
Brand positioning
High-risk industries
Use two modes:
auto_publish: low-risk content publishes automatically
manual_approval: high-risk content requires confirmation
Do not treat every content type as the same risk level.
A Minimum Viable Setup
For an indie developer:
1. Add status, scheduled_at, and published_at to content
2. Only approved and scheduled content can publish
3. A cron job scans publishable content every 5 to 15 minutes
4. Check title, body, image, slug, and links before publishing
5. Store publish status per channel
6. Lock publishing jobs and make them idempotent
7. Record failures and allow retry
8. Protect the cron endpoint with a secret
9. Update RSS, Sitemap, and notifications after publishing
This supports most personal content sites and early SaaS products.
Final Thoughts
Automated publishing is not only automating the “publish” click. It is automating the full path from review, scheduling, checks, publishing, retry, notification, and review.
Get states, checks, idempotency, and logs right first. Add more channels later.
More channels without process create more incidents. A stable process makes automation useful.
Next, we finish this stage with: What to Do on the First Day After Launch.
评论
0分享你对这一章的想法