Knowing when a run finishes
Start a long batch and walk away — the bell, an email, or a webhook tells you how it went, and you can narrow it to failures only.
In this article (5)
Nobody should have to watch a progress bar. Every run outcome — succeeded, failed, or needs review — can reach you on whichever channel you actually check.
The bell (on by default)
The bell in the top bar shows an unread count and a list of your recent run outcomes; click one to open that run. It refreshes on its own and clears when you open it. Nothing to configure.
The other channels
| Channel | Set up in | Best for |
|---|---|---|
| Settings → Preferences | Long or overnight batches — email | |
| Webhook | Settings → Preferences | Slack, Zapier, your own backend — webhooks |
| Digest | Settings → Preferences | One summary instead of a ping per run — digest |
All of them are per user and opt-in, and they only ever tell you about your own runs.
Narrowing what you get
Each of email and webhook has a notify on setting: every outcome, or only failures. Only-failures is the right default for a flow that runs on a schedule — silence means it worked.
Too noisy from one flow? Mute it, for you or (as an admin) for everyone.
What is in a notification
Which run, which workflow, the outcome, the estimated cost, and a link to the run. Never your API keys, and never the outputs themselves — a notification is a nudge, not a delivery mechanism. To move results somewhere, use the Send to a URL card or the Library's export.
Why this matters more once things are automated
A schedule or a trigger runs with nobody watching. Without a notification, a broken overnight flow is discovered days later — or by the invoice. Turn on at least failure notifications before you arm anything unattended.