Five scheduling mistakes that double-post or dead-post

Duplicate slots, 3am publishing, rate-limit collisions, timezone drift and the reconnect gap. The scheduling errors that are invisible in a calendar view and obvious in the analytics a month later.

By · · 6 min read

Drafted with AI assistance from our own research and Search Console data, and reviewed by Rahul A before publishing. Rules and prices change; check the linked official source before you act.

A scheduling calendar is a poor error-detection interface. It shows you what you intended, in a layout that makes conflicts look like adjacency. These five are the ones that survive a visual check.

1. The same post twice in the same minute

Usually from a CSV import run twice, or a bulk edit that duplicated rows. Some networks accept both and show both. Some accept both and dedupe silently. Neither is good, and the calendar shows two small blocks on the same day that look intentional.

Check: sort your queue by timestamp and network rather than viewing it by day. Duplicates become adjacent lines instead of overlapping blocks.

2. Posts inside the dead hours

Anything scheduled between roughly 01:00 and 05:00 in the audience's timezone is a post nobody sees. This is almost never deliberate; it comes from bulk-scheduling a batch with an offset, or from a “spread these evenly” feature that spreads them across the clock rather than across the waking day.

Check: filter for anything queued between 1am and 5am. If the answer is not zero, it was not on purpose.

3. Rate-limit collisions on the same account

Several posts to one account within a few minutes will trip per-account limits on most networks. The failure mode varies: a clean 429 you can retry, or an acceptance followed by a quiet drop. Two posts five minutes apart is usually fine. Four posts inside a minute is usually not.

Check: for each account, look for gaps under five minutes between consecutive posts.

4. Timezone drift

Two versions of this, and they bite at different times.

The first is scheduling in your local time for an audience in another. The second is worse: a scheduler that stores local time rather than an absolute instant. When daylight saving shifts, every future post moves by an hour. A queue built in February quietly slides in March.

Check: ask what the tool stores. If the API accepts and returns ISO-8601 with an offset or a Z suffix, it is storing an instant and you are fine. If it round-trips “09:00” with a separate timezone field, look closely at what happens across a DST boundary.

5. The reconnect gap

An account's token expires. You reconnect it a week later. Everything queued during that week either failed silently or is sitting in a state nobody looked at.

This is the one that combines with the others: it is invisible and it affects a whole batch rather than a single post. The defence is a warning before expiry rather than an error afterwards — a token with a known expiry date should generate a notice while there is still time to act.

Check: find your oldest connected channel. When was its token last refreshed? If the tool cannot tell you, that is the answer.

Making the checks automatic

All five are mechanical, which means none of them should be a human's job. They are pattern-matches over a list of timestamps and channels:

  • duplicate (time, network) pairs
  • hour-of-day between 1 and 5
  • same-network gaps under five minutes
  • times stored without an offset
  • channels whose token expiry is inside the queue's horizon

Our schedule validator runs the first three over a pasted schedule, in the browser, with nothing sent anywhere. The last two are properties of the tool you are using rather than of a particular schedule — PostWharf stores absolute instants and warns on channel.token_expiring before a channel goes dark.

Common questions

What causes a scheduler to post the same thing twice?

Most often two entries land in the same minute for the same account, or a retry fires after a call that had already succeeded. Timezone drift and reconnect gaps produce the same result.

What is a dead-hour post?

A post scheduled into a window when the audience for that account is asleep. It publishes correctly and reaches almost nobody, which makes it harder to notice than an outright failure.

How do I check a schedule before it runs?

Run it through a validator that looks for duplicate slots, dead hours, rate-limit collisions on the same account and impossible dates, while the schedule is still editable.

PostWharf is priced per workspace rather than per connected channel, and every plan carries unlimited channels. See per-brand pricing.