Notifications
Know when a run finishes, fails, or is waiting on you — in the app, in the browser, or on a messaging channel.
Long runs are the point of workflows, which means you will not be watching when most of them end. Notifications tell you what happened.
What raises one
| Event | Notification |
|---|---|
| A run needs a person | "… needs your input" |
| A scheduled agent's call needs approval | "… needs approval", with Approve and Refuse in the bell — see Scheduling |
| A run completes | Run completed |
| A run fails | Run failed |
| A run waiting on a person is cancelled | "… cancelled" — its question reads cancelled in the bell |
These come from the run's own lifecycle events, so every entry point produces them with no extra wiring — a run started from the UI, from the API, or by a schedule all notify the same way. There is nothing to enable per workflow.
Where they arrive
In the app — the bell at the foot of the menu lists them, with a count of unread ones, and a badge on the Workflows entry counts unseen runs; both are fed by a live stream, always on. What arrives while the app is open also shows as a toast. Anything that arrived earlier — or while the connection dropped — is in the bell when you come back, not toasted again. A question shows its words without markdown, in the bell and in the browser notification. An answered, cancelled or expired question stays in the bell, marked so.
In the browser — the same notifications as native browser notifications, so you get them with the tab in the background. The browser asks for permission the first time; if you decline, in-app notifications keep working.
On a messaging channel — a run that needs input can reach you on Slack, Discord, Telegram, Teams or WhatsApp, which is the difference between a human gate that blocks for an hour and one that blocks for as long as you take to read a message.
Unseen runs
The badge counts runs that finished while you were not looking, and clears when you open the runs list. It is a "since you were last here" marker rather than a queue you have to work through.
Notifications are best-effort, not a log
On a self-hosted install they are held in a bounded in-memory ring with best-effort persistence, so a restart can lose recent ones and the oldest fall off as new ones arrive. This keeps a single-process install free of any external dependency. For the authoritative record of what ran and what happened, use Runs › Logs.
On SynapseOrch Cloud
Cloud keeps notifications in your organisation's database, routes each event by role, and can send it by email too. Owners and admins choose who hears about what; each person can turn off what reaches them. See Notifications and email.
Usage Logs
Usage logs track token consumption and cost per agent run. Use them to understand which agents and workflows drive the most LLM usage.
Docker
SynapseOrch ships a Docker image that bundles the Python backend and Next.js frontend into a single container. Docker Compose is also supported, with its own Postgres.