When a BlueSky post does not show up right away, the cause is not always a failed publish. BlueSky is built on AT Protocol, so a record can exist on the account's PDS before every AppView, feed, search surface, or custom feed reflects it.
The practical troubleshooting question is: did the write succeed, and which view has not caught up yet?
Read BlueSky's read-after-write guide for why AppView responses can briefly lag behind PDS writes.
The four layers that affect post visibility
- PDS: the Personal Data Server where the account writes the post record.
- Relay: the aggregation layer that pulls repository updates from many PDS hosts.
- AppView: the service that indexes network data and serves feeds, profiles, threads, and timelines.
- Client UI: the app, browser, or custom feed interface that displays the indexed view.
A post can be successfully written to the PDS while a feed, profile, thread, or custom feed view is still waiting for the AppView or downstream service to index it.
Why posts can appear delayed
BlueSky's read-after-write documentation explains that AppViews are eventually consistent because they do not perform transactional writes directly against a user's PDS. The PDS can smooth over this in some routes, but not every view will be instant in every case.
This is especially visible when users refresh immediately after posting, when custom feeds have their own indexing logic, when a relay or consumer is catching up, or when a client has cached an older profile or feed response.
Firehose and relay lag
The Firehose is the event stream used by many services to sync repository updates. BlueSky's firehose guide explains that relays aggregate streams from PDS hosts into a unified stream for downstream consumers. If a consumer is behind, a post may exist but not yet appear where you expect.
Review BlueSky's Firehose guide for how repository updates flow through event streams.
Check whether the post actually published
- Confirm the post does not show after a hard refresh.
- Check the author's profile directly, not only the home feed.
- Check another browser or device to rule out client cache.
- If available, inspect the returned AT URI and CID from the publish operation.
- Wait a few minutes before retrying, especially during broader network lag.
Do not immediately publish the same post again. Duplicate retries can create spammy behavior and make the feed look broken even when the first write succeeded.
Timestamp mistakes can create confusing ordering
If a post uses a bad createdAt value, it can sort strangely. Before writing technical post records, check BlueSky createdAt timestamp formatting so the post has an explicit timezone and avoids far-future values.
BlueSky timestamp guidance says timestamps should include a timezone and avoid far-past or far-future values. Future timestamps can affect chronological sorting, so a scheduling tool should normalize time carefully.
Where ONYX fits
ONYX handles the scheduling handshake as part of the approved publishing workflow. The goal is to publish near the selected window, avoid duplicate retries, and keep the user focused on approved content instead of hand-managing PDS, relay, and AppView timing details.
Schedule approved BlueSky posts with ONYX when you want planned posts to publish without manual timestamp work.