Skip to main content

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.

Four ways to be notified

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.

Reaching a wider or different audience

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 appThe notification bell (this page)
Be emailed when a build failsFailure emails (this page): automatic, no setup
Have an external system told when a build completesOutbound webhooks: signed HTTP callbacks on build completion
Send a message from inside a running pipelinenotify-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​