Threads scheduled posts not working? Check which of the four quotas you hit
- Threads documents four separate rolling 24-hour quotas: 250 API-published posts, 1,000 replies, 100 deletions, 500 location searches.
- They are separate buckets — burning through replies does not touch your posting quota, and vice versa.
- There is a self-check endpoint, threads_publishing_limit, that returns your current usage across all of them.
- The quotas are per profile on a moving window, so a big batch this morning is still counted this evening.
You queued eleven posts. Six went out. Five sat there and then quietly failed. There was no error you could act on, no email, nothing in the app that explained it.
The instinct is to blame the tool. Sometimes that's right. But before you switch schedulers, it's worth knowing that Threads publishes hard numbers for exactly this, and gives you an endpoint to check where you stand. Most people troubleshooting scheduled posts have never seen either.
The four quotas, from the official documentation
Threads' developer documentation states four separate limits, each on a rolling 24-hour window, each measured per profile:
- 250 API-published posts within a 24-hour moving period
- 1,000 replies within a 24-hour moving period
- 100 deletions within a 24-hour moving period
- 500 location searches within a 24-hour moving period
Three things about this list are worth pausing on.
First, they're separate buckets. Replies have their own allowance four times the size of posts. If you're running a reply-heavy engagement workflow, that activity isn't eating into your publishing capacity. People frequently assume one shared pool and throttle themselves unnecessarily.
Second, deletions are capped at 100. That's the lowest number on the list, and it's the one nobody expects. If you're cleaning up after a misconfigured run, you can hit the deletion ceiling long before you've undone the damage — and then you're stuck waiting, with the bad posts still live.
Third, "moving period" is not "per day." There's no midnight reset. A batch you pushed at 9am this morning is still counted at 8pm tonight and only starts rolling off tomorrow morning. Schedulers that assume a daily reset will queue into a wall.
The endpoint that answers the question directly
This is the part worth taking away. Threads exposes:
<code>GET /{threads-user-id}/threads_publishing_limit</code>
It returns current usage across the quota types. That turns "I think something is rate limiting me" into a number you can look at.
If you build anything against the Threads API yourself, call it before a batch rather than after a failure. If you use a third-party tool, this is a fair thing to ask their support: does your product read the publishing limit endpoint before queueing, or does it just try and hope? The answer tells you a lot about how the product will behave on a busy day.
The documentation itself nudges developers in this direction, noting that apps should enforce publishing rate limits "especially if your app allows app users to schedule posts to be published in the future." That sentence exists because scheduling is precisely where quota mistakes accumulate invisibly: the failure happens hours after the human walked away.
Why native scheduling and API scheduling behave differently
Threads has native scheduling in the composer, and it's free. The quotas above describe API-published posts, which is what third-party tools use. These are different paths with different accounting, which is why two people can report completely contradictory experiences of "how many can you schedule."
One consistent limitation across both, worth knowing before you design a workflow around it: replies are not schedulable. Meta has kept conversation real-time by design. If your plan involves queueing a thread of replies to go out over an afternoon, that plan needs rethinking regardless of tool.
On the question of how far ahead native scheduling reaches, you'll find a specific number repeated widely. We couldn't source it to Meta's own documentation, and the versions don't fully agree, so we're not going to repeat it. Open the composer, tap through to the date picker, and look at the furthest date it will let you select. That takes ten seconds and it's true for your account, which no article can be.
When a limit matters to your workflow, the date picker in front of you is a better source than any article — including this one. Articles describe the average account. The picker describes yours.
A troubleshooting order that actually converges
When scheduled posts fail, work through this in order rather than randomly retrying:
- Check the publishing limit. Either via the endpoint or by asking your tool what it saw. This resolves a large share of cases immediately.
- Check whether the failures are replies. If your "scheduled posts" are actually replies, they were never going to work.
- Check the media. Publishing is a two-step flow — create a container, then publish it. A container that failed to process leaves you with a publish call that has nothing to publish, and the surfaced error is often unhelpfully generic.
- Check token state. Expired or revoked authorisation produces silent failures in a lot of tools rather than a loud one.
- Only then blame the scheduler. By this point you'll have enough detail to file a support ticket that gets a real answer instead of "try reconnecting your account."
What this means if you run several accounts
The quotas are per profile, which is the good news: ten profiles means ten separate allowances, not a shared pool you divide up. The bad news is that a single tool posting on behalf of all ten is making all those calls under its own app, and app-level throughput is a different constraint from profile-level quotas — which is why bulk publishing sometimes gets slower for everyone on a platform at once, for reasons that have nothing to do with your account.
There's an architectural fork here worth understanding. Everything above applies to tools that publish through the official API. Tools that publish through a browser session you're already logged into — the approach NoobClaw takes — aren't governed by those API quotas at all, because there's no API call being made; they're governed by the platform's ordinary user-facing limits instead. Neither is universally better. API publishing is more reliable and observable; session publishing isn't exposed to developer quotas or API pricing but needs a machine running and behaves like a very fast human. Pick based on which set of constraints matches how you actually work.
Designing a queue that does not hit the wall
If you are regularly bumping into these limits, the fix is usually the shape of the queue rather than its size:
- Spread rather than batch. A moving 24-hour window punishes bursts specifically. Two hundred posts spread across a day sit comfortably inside a 250 allowance; two hundred posts in one hour leave you with nothing for the next twenty-three.
- Budget deletions. One hundred is the smallest of the four numbers and the one people never plan for. If a workflow involves publishing and then cleaning up, the cleanup is the constraint, not the publishing.
- Keep replies out of the publishing budget mentally. They are a separate bucket, and treating them as one is leaving capacity on the table.
- Check before, not after. One call to the publishing limit endpoint at the start of a run tells you whether the run will finish.
The general principle behind all four: a rolling window means your past self is competing with your present self for capacity. Any scheduler that reasons in calendar days will eventually queue into a limit that a human would have seen coming.
Related reading
For the quotas in more depth, see Threads API rate limits explained. If the problem is reach rather than publishing, Threads not getting views covers that separately, and how many hashtags Threads actually supports is a common follow-up. For the equivalent failure on another platform, see scheduled post failed to publish on Instagram.
FAQ
Do replies count against my 250 posts?
No. Replies have their own 1,000-per-24-hours allowance. They are separate buckets, which means heavy engagement activity does not reduce your publishing capacity.
Why did my posts work this morning and fail this evening?
Because the window is a moving 24 hours, not a calendar day. The morning batch is still being counted in the evening. There is no midnight reset to wait for — you wait for the earliest posts to roll off, one at a time.
Can I schedule replies on Threads?
No. Meta has kept replies real-time deliberately. Any workflow that depends on queued replies needs to be redesigned around that, not worked around with a different tool.