Activity feed
What went out, what did not, and why. In one feed you can hand to a client.
When a post does not appear, the question is always the same: did we schedule it, did it fail, or did it publish and get deleted? The activity feed answers that in one place, with the platform’s own error text on anything that failed and a retry next to it.
Every publish and failure, with retries.
Capabilities
What you get with Activity log.
- Failures carry the platform’s own words
- A stable reason code drives what you see, and the raw text the platform returned is kept alongside it. So a vague failure is still diagnosable rather than reduced to "something went wrong".
- Retry from the feed
- A failed publish is retryable in one click from where you found it, without rebuilding the post or hunting for it in the calendar.
- Answers the audit question
- What went out, to which channel, when. That is the report an agency needs when a client asks about last month, and it is a read rather than a reconstruction.
- Emails only for what you must act on
- Transient failures retry quietly. You are emailed for the unrecoverable ones — a revoked token, a channel that needs reconnecting — rather than for every hiccup.
The three-way question
A post is not where you expected it. There are exactly three explanations, and they need completely different responses:
- It was never scheduled. Somebody thought they hit schedule and did not, or it is still a draft.
- It failed. The platform refused it, or a token expired.
- It published. And then it was deleted, or you are looking at the wrong account.
Without a log, distinguishing these means opening the platform, checking the calendar, and asking a colleague. With one, it is a glance.
Codes and raw text, both
Every failure carries a stable reason code, and separately, the raw text the platform returned.
Both exist for different readers. The code is what gets shown and translated, and it is stable enough to build on — so "channel disconnected" means the same thing every time regardless of how the platform phrased it this week. The raw provider text is kept because platform errors are sometimes specific and useful in a way no generic code can be, and throwing it away makes support conversations guesswork.
Holds are visible, and they are not failures
Some states are not the post's fault:
- The channel was disconnected.
- The token expired and needs a reconnect.
- The workspace has no active subscription.
Those hold the post — it stays scheduled, and it shows up as needing attention. Marking them as failures would destroy the schedule and force a per-post retry, when in reality one action fixes every affected post at once. Reconnect the channel and the whole queue resumes.
"Disconnected" in an email or a notification means the token needs reconnecting. It does not mean somebody removed the channel — that only happens when a person clicks disconnect.
As a client report
The feed doubles as the answer to "what did you publish for us last month". Channel, content, time, outcome, in one list.
For giving a client an ongoing view rather than a monthly answer, a share link puts the calendar itself in front of them without creating an account.
Found this useful? Pass it on.
Questions
Frequently asked questions Everything the first evaluation usually needs.
- What does the activity feed show?
What happened to your posts: publishes, failures, and the retries that followed. Each failure carries a reason and the platform’s own error text.
- How do I retry a failed post?
From the feed, in one click. Retry is only offered on posts that have actually settled as failed, which is what stops a retry racing a publish attempt that is still running.
- Will I be emailed every time something fails?
No. Transient failures — a rate limit, a brief platform outage — are retried automatically with backoff and do not email you. Unrecoverable failures, such as a revoked token, do.
- Can I see why a post failed rather than just that it did?
Yes. Failures carry a stable code that drives the message you see, and the raw provider response is retained for support. Both matter: the code is translatable, the raw text is diagnosable.
- Does the feed show posts that were held rather than failed?
Yes, and the distinction is deliberate. A disconnected channel or a lapsed subscription holds posts as scheduled instead of failing them, so reconnecting or paying resumes the whole queue at once.
- How far back does it go?
Your workspace’s history is kept, so the question "what went out last quarter" is answerable rather than being limited to a recent window.
Keep reading
- Queue & reliabilityA queue that flags a post at risk before its publish time, refuses to send something an hour late, and turns a crashed worker into a retryable failure.Read
- Team collaborationInvite teammates with owner, admin, or member roles, leave threaded comments on a draft, and route posts through approve, reject, or request-changes first.Read
- Client approval calendarSend a client a link to their content calendar. They comment and approve in the browser without an account, and you revoke the link once the engagement ends.Read