We health-check every publishing connection on a daily schedule: can we still authenticate against the platform and reach the target blog? A connection that fails its check is marked unhealthy on the integrations tab, so you find out before the next article tries to publish into a dead connection — not after it fails at 6am.
What to know before you start
Check the health state whenever publishes start failing, and after anything changes on the platform side — password rotations, app reinstalls, plan changes, site migrations. Most connection deaths are caused by a change nobody thought would matter.
There's nothing to schedule — checks run daily on their own. To re-verify immediately after fixing credentials, save the connection again. Saving re-tests it.
Repair an unhealthy connection
A healthy connection has authenticated recently. An unhealthy one names the failure it hit — authentication, permissions, or unreachable target.
To repair it, work through these in order — it's the order that resolves most cases:
- Re-paste the credential. Tokens rotate when apps are reinstalled, keys are regenerated, or passwords are reset. This fixes the majority outright.
- Check scopes. The credential works but lost a permission — recreate it with the scopes listed on the platform page for your connection.
- Check the target. The blog, collection, or location was renamed, deleted, or unpublished. Point the connection at the current target.
Limits and usage
- Health checks are lightweight authentication probes — they don't publish anything or count against content quotas.
- The nightly sweep tests up to 60 connections per run, oldest-checked first, so a break usually shows unhealthy within a night — a very large base is swept over several nights. A check that fails without a clear refusal — the site answers with a server error, times out, or a firewall challenges us once — keeps the connection healthy and records the error; a second failure in a row marks it unhealthy. A rejected credential, an address that is not the platform, or an account that cannot publish marks it at once. A manual publish that fails at the connection marks it right away; a queued send marks it after its final retry. Article-level rejections never mark the connection.
If something isn't working
The connection is healthy but publishes fail. The check proves auth, not content acceptance — a full disk, a plan limit, or an item cap on the platform can refuse posts from a healthy connection. The publish error names the refusal.
The connection flaps between healthy and unhealthy. The platform is rate limiting or intermittently down. If it persists across days, rotate the credential anyway — flapping auth is often a token near expiry.
Does an unhealthy connection stop my scheduled articles?
New ones, yes. Auto-publish only queues articles to connections whose last check passed. Sends already in the queue keep retrying on the hourly runs, then park with their error.
Once I've fixed the problem, does the state clear on its own?
Yes. The next nightly sweep re-tests and flips it back to healthy — and you don't have to wait: pressing Test, or any successful publish, clears it immediately.
Can a health check change anything on my site?
No. The sweep only reads — it authenticates and asks the platform who it is. It can never publish or modify content.