Notifications
Loha has a real-time notification bell in the app bar: the quickest way to know a build finished without leaving the page you're on. It's a personal inbox: the bell follows you across every workspace you belong to.
The bell is one of four notification mechanisms, and they don't overlap. Use the bell
for yourself in the app, failure emails to reach the person who
triggered the build and the workspace admins, outbound webhooks
to tell an external system, and the notify-line /
notify-webhook steps to send a message from inside a
running pipeline. The contrast table below picks the right one.
The notification bell
The bell lives in the app bar (shipped in the dashboard, and now in the customer portal too). When a build reaches a terminal state (succeeded, failed, or timed out), Loha writes a notification for you.
- Unread count: the bell shows a badge with the number of unread notifications.
- Dropdown list: clicking the bell opens your notifications newest-first, each showing the build's status and when it finished.
- Click to open: clicking an item opens that build and marks the notification read.
- Mark all read: clears the unread count in one click.
Notifications are user-scoped: they're tied to your account, not to a single workspace, so the bell aggregates builds from every workspace you're a member of.
How fresh it is
Delivery is live over Server-Sent Events (SSE): when a build finishes, the bell updates without a refresh. A periodic refresh (roughly every 30 seconds) acts as a fallback if the live stream drops, so you never miss a notification.
Failure emails
When a build fails or times out, Loha emails the person who triggered it (when a person did) and every workspace owner and admin. Builds started by a webhook, a schedule or a service account have no human actor, so those reach owners and admins only. Successful builds don't send email; they show up in the bell instead.
There is nothing to configure. The audience is worked out at the moment the email is sent, from your current workspace membership, so it stays correct on its own: add someone as an admin and they start getting failure mail; remove them and they stop. Loha never keeps a separate list of addresses to notify.
To narrow what you personally receive in the app, use the notification preferences on your account: you can mute a workspace entirely, or limit the bell to builds you triggered yourself.
To alert a channel your team actually watches (Microsoft Teams, LINE, an incident tool),
use outbound webhooks or a
notify-* step in the pipeline itself. Routing build and
deploy events to a named on-call audience is not available today.
Which one do I want?
| You want to… | Use |
|---|---|
| See your own build results while using the app | The notification bell (this page) |
| Be emailed when a build fails | Failure emails (this page): automatic, no setup |
| Have an external system told when a build completes | Outbound webhooks: signed HTTP callbacks on build completion |
| Send a message from inside a running pipeline | notify-line / notify-webhook steps |
The distinctions that matter:
- The bell is in-app and personal: no setup, no endpoint, nothing to verify. It reacts to your builds finishing.
- Failure emails are automatic and need no configuration: they reach the build's trigger actor and the workspace's owners/admins, resolved from membership at send time.
- Outbound webhooks are workspace- or trigger-scoped signed HTTP callbacks Loha sends to a URL you control when a build reaches a terminal status, the right tool for relaying results to Slack, an incident tool, or downstream automation. They're configured in Settings → Webhooks and verified by signature.
- Notify steps run inside a pipeline as ordinary build steps, so they fire at the exact point in the pipeline you place them (e.g. "deploy succeeded, now ping the release channel") and can use values produced earlier in the run.
Where to go next
- Builds: the terminal states that trigger a notification
- Outbound webhooks: notify an external system on completion
notify-line·notify-webhook: notify from inside a pipeline