Notifications
4 min read
Notifications let you know when something needs attention. They arrive through two separately enabled routes: email and the dashboard (the bell icon in the toolbar).
What you are notified about
- Approvals: one is pending, or an agent has asked you a question.
- Agents: one failed, ran out of provider allowance, has an expired credential, or raised an alert.
- Cost: an agent crossed its maximum usage rate, or the context loaded on each step is using up its allowance.
- Servers: a machine has spent too long over its CPU, RAM, or load threshold.
- Backups: a backup failed or was empty.
- Models: a connection's Claude subscription is about to expire (30 and 7 days out).
- Plan and payments: a trial ends, the plan is downgraded, the grace period ends, or a charge succeeds or fails.
- Platform notices: maintenance and new features we publish.
Agent alerts
An alert is the notice an agent sends when something cannot wait: a service has broken, there is a risk requiring attention, or it needs human intervention to continue. It is one-way; the agent does not remain blocked waiting for a response.
Do not use it as a progress update or to confirm that a task has ended. Routine notices make important alerts less useful.
| Severity | When to use it |
|---|---|
| Information | A relevant situation worth knowing about, without immediate urgency. |
| Warning | Something that needs attention soon or could become a problem. |
| Error | A service, process, or resource is actually blocked or has failed. |
Who receives them
Kujira resolves recipients in this order:
- Thread participants. In a one-to-one conversation, the alert reaches the people participating in it. A notice about a private conversation is therefore not automatically distributed to the rest of the organization.
- Recipients configured in the channel. If an alert starts in a group, scheduled task, or context without a particular person, it uses the list selected in that channel.
- Nobody. An empty recipient list does not mean “all administrators”: it means those collective alerts interrupt nobody.
Set alert recipients in channel configuration so notices from that source always have clear owners.
Approvals follow a different rule
An approval needs a decision to unblock the agent. If it finds neither configured recipients nor a person responsible for the thread, it escalates to organization owners and administrators. Alerts do not escalate automatically.
Alerts do not replace an approval
An alert informs and the agent may continue. If an action needs a human decision before it runs, it must create an approval.
Choose what you receive
In My account › Notifications, settings are per organization: choose an organization from the list and adjust its notification table, choosing email, dashboard, both, or neither for every type.
If you belong to several organizations and want the same setup for all of them, use Apply this configuration to all.
Recipients depend on the notice
Technical, plan, and platform notices go to owners and administrators. Alerts, questions, and conversations follow the thread context or the recipients you selected in its channel.
In the dashboard
The dashboard lists the most recent notices, marks unread ones, and takes you directly to where the event occurred. Every alert also has a unique code (ALT-…) used to refer to a specific notice with a colleague or support. Next to its link, it lets you reach that exact alert, even when you need to switch organizations to open it.
Dashboard notifications are retained for 90 days.
Browser notifications
On the same screen, you can also ask the dashboard to notify you when an agent finishes a task you requested: select the agent and session, with a subtle sound or a browser notification when the tab is in the background.
This is stored only in this browser; it is not an account preference.