How to Schedule Mastodon Posts in 2026 (Postiz Guide)

What most “Mastodon scheduler” guides get wrong

Search for a tool to schedule Mastodon posts and most pages describe Mastodon as a platform with no scheduling support at all. That was true until Mastodon 2.7.0 added the scheduled_at parameter to POST /api/v1/statuses. The official Mastodon API documentation states it plainly: when scheduled_at is present, the endpoint returns a ScheduledStatus instead of a published status.

So the accurate framing in 2026 is not “Mastodon cannot schedule posts.” It is that native scheduling is capped, per-instance, and lives on the server. If you run one account on one instance, the native queue may well be enough. If you post across several accounts and instances, or you want to plan a month of content in one view, the instance-side caps become the binding constraint.

The limits are defined in Mastodon's own ScheduledStatus model and are worth memorising before you plan around them:

• 25 scheduled statuses per day, counted by calendar date
• 300 scheduled statuses total across the account
• A five-minute minimum offset — anything closer is rejected as “too soon”
• 500 characters maximum for a single status
• Four media attachments per status

How to schedule Mastodon posts: the two approaches compared

There are only two real ways to schedule Mastodon posts, and the difference between them is where the queue lives. That single architectural choice explains nearly every practical difference between tools.

This is not a hidden implementation detail. It is verifiable in Postiz's own provider source, which never sets scheduled_at at all. Instead it uploads media first, waits for the instance to finish processing it, then posts the status itself at the due time.

That last line matters more than it looks. Mastodon documents the Idempotency-Key header and stores keys for up to an hour, so a finalize retry after an unclear network outcome returns the already-created status instead of posting twice. Postiz generates a fresh key per publish run rather than reusing the database post id, because reusing the id would make an edited post silently return the old toot.

How to set up Mastodon in Postiz

Mastodon is the unusual case among the platforms Postiz supports, because there is no app to download and no developer console to click through. Client registration happens over HTTP against the instance itself.

For a self-hosted Postiz install, you register the app with curl and point it at your instance:

The redirect URI has to match the environment exactly — http://localhost:4200/integrations/social/mastodon for local development, http://localhost:5000/integrations/social/mastodon for Docker, and https://your-domain.com/integrations/social/mastodon in production. Then you set three environment variables and restart:

On Postiz Cloud you skip all of this — every platform is already registered for you.

Connecting a community-run instance

Most people do not post on mastodon.social. They post on a niche instance: a city server, a gaming community, an arts server, a self-hosted instance they run themselves. Postiz ships a second provider for exactly this case. The custom-instance provider posts to the instance's /api/v1/apps endpoint itself, registers the OAuth application with the correct redirect URI and scopes, and hands back a client id and secret. No manual app registration, no remembering to register a second app when you switch instances.

One catch worth knowing: Postiz's public API endpoint for generating OAuth authorisation URLs only supports platforms that use a standard external URL. Because a Mastodon instance URL is user-supplied, Mastodon connections are not available through that endpoint — you connect them through the interface.

What actually goes wrong when a scheduled Mastodon post fails

Media handling is where scheduling on Mastodon gets genuinely tricky, and it is where most “it just didn't post” complaints come from. Mastodon processes uploaded media asynchronously, and attaching a video or a large GIF before the instance has finished transcoding it fails with a 422.

Postiz splits publishing into three phases to handle this properly. Media uploads first and the provider waits. Then it polls the media endpoint, which answers 206 while processing is still running and 200 once the file is ready. Only after every attachment is confirmed ready does it create the status.

That 404 case is the subtle one. After a finalize whose outcome was lost, an already-published status makes its media return 404. A naive implementation reads that as “expired, repost again” and creates a duplicate toot. Postiz instead continues checking the remaining attachments and lets the idempotent finalize either deduplicate into the existing status or get Mastodon's verdict.

If you hit media problems specifically on a self-hosted setup, the Postiz Mastodon provider documentation has the fix. When your instance hostname resolves to a private IP from inside the container — common behind Caddy, split DNS or hairpin NAT — the SSRF guard blocks the media fetch and you get Error: Blocked IP while text posts publish fine. The documented remedy is DISABLE_SSRF_PROTECTION=true on a trusted private network, or better, fixing name resolution so the guard stays on.

Postiz vs Buffer vs Mastodon-only tools for Mastodon posting

Buffer added Mastodon support in January 2023 and is a credible option if Mastodon is one of two or three channels you manage. Its free plan allows three connected channels with ten scheduled posts per channel, and paid tiers are priced per channel per month. Buffer genuinely wins on polish, on its community inbox for replying across networks, and on how little friction there is in the interface.

Later and Hootsuite are the wrong shape for this particular problem. Neither lists Mastodon among its supported channels, so you would be running a second tool for a second network and reconciling two calendars by hand. Publer does list Mastodon alongside Bluesky and Telegram, which makes it a closer match than those two.

And the Mastodon-native tools deserve real credit. Postpone, SawirPost, Prasar and Postopus are built around one network, so they can offer Mastodon-specific niceties — visibility controls, per-instance character handling, thread previews — that a unified scheduler skips. Postopus, for example, currently supports X and Bluesky with Mastodon listed as coming soon, which shows how quickly this category moves. If Mastodon is 90% of your posting, a native tool is a legitimate choice.

Postiz's own advantage is specific rather than absolute. It supports 34 platforms, including the federation-adjacent ones most schedulers skip: Mastodon, Bluesky, Lemmy, Farcaster, Nostr, Telegram, Discord and Slack. It is open source with a self-hostable Docker image, which means no channel cap on a self-hosted install and full control over where your content queue and credentials live. Plans start at $29/month for 5 channels, with Team at $39, Pro at $49 and Ultimate at $99 for 100 channels — and every plan includes unlimited posts per month.

You can see the difference in the numbers. Buffer's per-channel pricing means a fifteen-account operation costs fifteen times the entry price. Postiz prices by tier, not by channel, so adding a second Mastodon account on the same plan costs nothing extra.

Scheduling Mastodon threads and visibility

Two details bite people who assume Mastodon behaves like X. First, threads: on Mastodon a thread is a chain of statuses where each reply references the previous one by id. Postiz handles this by publishing the parent and then replying against it, so you queue the parent and each reply as separate entries in order. Because native scheduling enforces a five-minute minimum, a long thread scheduled on the instance itself needs generous spacing between every part.

Second, visibility. Mastodon posts can be public, unlisted, private (followers-only) or direct. Postiz's provider sets visibility: public by default on the status payload, so if you need unlisted or followers-only toots you will want to check how the instance's own preferences interact with that default before you publish a batch.

Character counting is the last surprise. Mastodon counts 500 characters and, like Twitter before it, a URL always counts as a fixed 23 characters regardless of its actual length. Long links eat your budget silently, which is another argument for keeping Mastodon copy separate from your X copy rather than cross-posting the same string unchanged.