Skip to main content
She works while you are not watching, so the way you find out a post failed is a notification. Two places carry them: the bell in the app, and your inbox.

​
The bell

Notifications collect in the app and stay there until you clear them. Newest first, a hundred to a page. What lands there is anything you would want to know without asking: a post that published, a post a network refused, a channel whose connection went stale, an invitation to an organization. The ones worth acting on immediately are failures, because a failed post does not retry itself. When a post fails covers what each kind means.

​
Emails

Three toggles under Settings > Global Settings, all on by default: Turning one off leaves the bell alone: the notification still appears in the app, you just stop getting mail about it.
Think before turning Failure Emails off. A failed post is silent otherwise unless you happen to open the app. If the volume is the problem rather than the emails themselves, the usual cause is one channel with a dead token failing repeatedly, and reconnecting it stops the noise at the source.
Self-hosting? No mail of any kind goes out until EMAIL_PROVIDER is set, whatever these toggles say. The bell still works. Email Notifications sets it up.

​
Reading them from outside the app

The public API exposes the same list, which is the practical way to watch for failures from a script or a dashboard:
A hundred per page, newest first, page starting at 0. Full reference: List Notifications.
There is no notification tool over MCP and no CLI command for this, so an agent cannot tell you what failed. The API is the only route. CLI limits lists the other gaps.

​
Next steps

When a post fails

What each failure means and which ones need you

Set up email

Self-hosting: nothing is delivered until a provider is configured

Webhooks

Push the same events to your own endpoint instead of waiting for mail

Settings

Every tab, and why some are missing for you