Module 4 — Communication · Lesson 4.6
Notifications, Alerts and Quiet Hours
The notification center, the delivery channels, and getting push to actually work
~11 min
What you'll learn
- Read and clear the notification center, including agent alerts
- Tune per-type delivery across in-app, email and push
- Register a push transport so push notifications can actually arrive
- Set do-not-disturb and understand which channels it enforces
Notification settings are the least interesting page in any product and one of the most consequential, because a system whose alerts do not arrive is a system people learn to distrust. Kavanah's has one setup step that is easy to miss and produces exactly that outcome.
The notification center
Alerts sits at the bottom of the sidebar. It collects mentions, replies, project notifications and agent alerts.
Agent alerts are the category worth a second look. They are how the agent tells you something needs you — an action parked for approval, a broken integration, a decision suggestion waiting, a scheduled run that produced something. They also appear in the dashboard right rail, which is the faster daily read.
Read and clear. A notification center with four hundred unread items is a notification center nobody reads, and the fix is either clearing it or tuning what generates entries.
Delivery channels
Settings → Notifications is where you choose how each type reaches you: in-app, email, push, and do-not-disturb.
The general shape that works: in-app for everything, email for things that need you when you are not in the app, push only for things that are genuinely time-sensitive. Push for everything trains you to dismiss push, at which point it is worth nothing.
Tune per-type rather than globally. The value of the settings page is precisely that mentions and project updates can have different answers.
The step people skip: registering a push transport
This is the important part of the lesson.
Turning push notifications ON in settings is not the same as being able to receive them. Push needs a registered transport — a device that has actually asked for permission and been registered. On the web that means accepting the browser's notification prompt; on mobile it means accepting the OS prompt in the Kavanah app; on desktop it means the same in the desktop shell.
If nobody in a workspace has done that, push notifications reach nobody, and nothing anywhere says so. The settings page looks correct. The alerts are generated. They simply have nowhere to go.
This has caused real escalations — a team assuming they would be notified, no notification arriving, and the incident being found late. So the check is: after enabling push, actually confirm you receive one. Send yourself something. If it does not arrive, you have a transport problem, not a settings problem.
Quiet hours and do-not-disturb
Do-not-disturb suppresses delivery during hours you set.
Be aware of what it does and does not reach. Email and push are suppressed. In-app notifications still accumulate — which is the correct behaviour, because they are not an interruption; you see them when you next look.
Set it to your actual working hours rather than aspirational ones. The purpose is that a notification arriving at 11pm is one you were not going to act on until morning anyway, and receiving it just costs you the sleep.
One note for teams spanning timezones: quiet hours are per person and resolve against each person's profile timezone. That is the correct behaviour and it is another reason the timezone field matters.
Make notifications trustworthy
- 1
Get it to zero once. A permanently full center is one nobody reads, including when it matters.
- 2
Settings → Notifications. In-app for everything, email for away-from-app, push only for time-sensitive.
- 3
Register a push transport and TEST it
Accept the browser or OS prompt, then confirm you actually receive one. Enabling push in settings does not create a transport.
- 4
Set do-not-disturb to your real hours
Email and push are suppressed; in-app still accumulates, which is what you want.
What to watch
- Push transport coverage
- How many workspace members have at least one registered push device.
- Healthy signal: Everyone who has push enabled. A gap here means alerts are being generated for people who cannot receive them, and nothing reports it.
- Unread backlog
- Size of the average member's unread notification count.
- Healthy signal: Small. A large backlog means notification types are over-generating and need tuning, not more discipline.
- Time to acknowledge an agent alert
- How long a parked approval or broken-integration alert waits before someone acts.
- Healthy signal: Hours, not days. This is the number that tells you whether the alerting path actually works end to end.
Key takeaways
- ·Alerts collects mentions, replies, project events and agent alerts; the dashboard rail is the faster daily read.
- ·Tune delivery per type — push for everything makes push worthless.
- ·Enabling push is not the same as having a push transport; register a device and TEST that one arrives.
- ·Do-not-disturb suppresses email and push; in-app still accumulates, which is correct.
- ·Quiet hours resolve against each person's profile timezone.
Module 5 moves to measurement: where the hours actually go, what fits in the sprint, and what the reports can tell you.