MDZelo
首页/Indie Hacker Guide/How to Automate Publishing

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:

What Should Be Automated

Not all content should be automatically published.

Good candidates:

text
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:

text
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:

text
draft
reviewing
approved
scheduled
publishing
published
failed
archived

Do not rely only on published=true.

Clear states make the next action obvious.

For example:

text
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:

text
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:

text
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:

text
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:

text
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:

text
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:

text
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:

text
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:

text
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:

text
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:

text
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:

text
First publish to a new channel
Large batches
Pricing and promises
Brand positioning
High-risk industries

Use two modes:

text
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:

text
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

分享你对这一章的想法

还没有评论成为第一个分享想法的人。