Automating social without your account going quiet

Social automation fails in a way that is unusually easy to miss. The account does not get banned with a notification. It quietly stops accepting posts, the job keeps running, and three weeks later somebody asks why the feed has gone dead.

Almost all of it comes down to credentials, and credentials are the part every tutorial skips.

Long-lived does not mean permanent

The single most expensive misunderstanding in this space is the phrase “never expires”.

A long-lived access token typically lasts around sixty days and can be refreshed. But sitting behind it is a separate clock: the data access window, which is roughly ninety days from the last time a human actually authorised the app. Refreshing the token does not reset that window. Only a person going through the authorisation flow again does.

So a system can refresh diligently, report healthy every day, and still stop dead on a date nobody has written down anywhere.

Put the real deadline in a calendar with a human’s name against it. It is the one part of this that cannot be automated, by design.

Refresh on a schedule, and check the refresh

The pattern that works is unexciting.

• Refresh monthly, well ahead of any sixty day expiry. Do not wait for a failure to trigger it.
• Store the new token and the new expiry together, so the system knows its own deadline.
• Alert when a refresh fails. This is the step people skip. A refresher that silently fails is worse than no refresher, because it creates the belief that the problem is handled.
• Warn at fourteen days remaining regardless of what the last refresh said.

We have watched forty six consecutive publishing runs fail against an expired credential, all of them exiting cleanly, because the failure was caught, logged at debug level, and treated as a normal outcome.

Not every failure is the token

Two that cost us real time, and neither was a credential.

Network stack mismatch. A batch of publishing failures looked exactly like authentication errors. The token was fine. The host had an IPv6 record, the runner was IPv4 only, and connections were failing before authentication ever happened. The API returned something close enough to an auth error that it sent us hunting in entirely the wrong place for a day. Pinning the runner to IPv4 fixed it.

The job outran its own timeout. A multi-image carousel took longer than the platform’s execution window. The run was killed midway, having posted to one network and not the other, and the retry started from the beginning and posted the first one again. One outage, two symptoms: a missing post on one channel and a triple post on the other.

The fix was making each platform resumable independently, so a retry picks up where it stopped rather than starting over. If you publish to more than one network in a single job, build this before you need it.

Rate limits are a design input

Every platform limits how much you can post and how fast. Treat those numbers as part of the design rather than as errors to handle.

Spread posts across the day rather than firing a batch at midnight. Back off exponentially on a rate limit response instead of retrying immediately, which on most platforms extends the block. And know which of your accounts share a limit, because on several networks a business account and its linked page draw from the same pool.

What the monitoring has to answer

For social specifically, four questions. All of them are about outcomes rather than runs.

• Did the post appear on the platform? Query the platform and confirm the object exists. The job’s own log is not evidence.
• How many days until the credential expires, and until the authorisation window closes? Two separate numbers.
• When did each channel last publish successfully? Per channel. An aggregate hides the one that stopped.
• Did anything post twice? Duplicate detection catches the resumability bug above, which otherwise looks like success on both attempts.

The realistic version

Social automation works well and is worth building. What it is not is unattended. Roughly once a quarter something will need a human: a re-authorisation, a changed endpoint, a policy update.

Build for that rhythm and it is a small, predictable maintenance cost. Assume it will run forever untouched and you will discover the real schedule the hard way, three weeks after your feed went quiet.