Notification preferences

Your per-user notification settings live at `/settings/notifications`. Nothing here affects your teammates, and nothing here overrides the routing policies that decide which incidents exist in the first place.

> This page has no menu entry — you have to type the URL. There is no link to

> it from the sidebar, the Settings page, or the user menu. And the Settings

> item in the sidebar is admin-only, so a Manager or Viewer has no Settings entry

> at all.

> So if you are on-call and were told to set a preference here, navigate directly

> to /settings/notifications. Being unable to find it in the menu does not mean

> you lack access — the page itself is available to you for your own preferences.

> Tracked as todo/0029.

Read Routing policies first if you are trying to change *who* gets paged — that is a different screen, and it is the one that decides delivery for the team.

What actually takes effect today

Be aware of this before you spend time on the page, because the three sections are not equal:

Section	Stored	Enforced
Event Preferences	Yes	Yes
Digest Mode	Yes	No
Quiet Hours	Yes	No

Digest mode and quiet hours are accepted, validated, and saved, and the UI describes what they will do — but the notifier does not consult them yet. Setting "Daily digest" or a 22:00–08:00 quiet window today has no effect on delivery; you will be notified exactly as if they were unset. The server logs a warning when it stores one.

Set them if you want your intent recorded for when they land. Do not rely on them to stop a 3am page.

Event Preferences

This section answers one question: **when ObserveKit needs to reach *you* personally, which of your channels should it use?**

"Personally" is narrow and worth stating exactly. Today it means one thing — an escalation policy step whose target is you as a user rather than a channel. When that step fires, the engine reads your preferences here to decide where to send it.

Row	Read when
Acknowledgement expired	Checked first — for every user-targeted escalation step, not only ack expiry.
Default	The fallback, used whenever the row above is empty.

The name is misleading, and it matters. The resolver looks up *Acknowledgement expired* first for any escalation step aimed at a user, including the very first step fired the moment an incident opens. So setting it does not route ack-expiry somewhere special — it redirects all of your user-targeted escalation, and *Default* is then only consulted when this row is empty.

If you want one destination for everything, set Default alone and leave this empty. Setting both, with different channels, means the top row wins everywhere and the fallback never fires.

The channels offered are the ones from Settings → Notification Channels.

You need to be an admin to see them. Listing notification channels is an

admin-only API, so a Manager or Viewer opening this page gets an empty channel

list — not because none exist, but because they may not read them, and they

cannot create one either. The page says which of the two it is rather than

leaving you to guess.

That matters here more than it looks: an escalation policy's user targets are

usually on-call engineers, who are usually not admins. If you are named on a

policy and cannot set a preference, the options are to have an admin point that

escalation step at a channel directly, or to be granted admin access. Tracked as

a product gap, not a setting you can change.

If you *are* an admin and the list is genuinely empty, add a channel under

Settings → Notification Channels first.

If you are named on an escalation policy, set one of these

An escalation step aimed at a user with neither row set has no channel to deliver to. It fails with *"prefs contain no channel IDs"* — at the exact moment the escalation was supposed to page you.

Setting Default alone is enough, and is the sensible minimum. Use Acknowledgement expired only when you want that specific case to go somewhere different.

Why these two rows and not more

Only keys some part of ObserveKit actually reads are offered. The page previously listed Assignment and Mention as well; neither event is emitted anywhere in the product, so those rows stored a preference that nothing could ever act on.

Worse, the three rows it did offer were spelled differently from the two keys the escalation engine looked up, and nothing translated between them — so ticking a channel under "Ack Expired" saved successfully and configured nothing. That was a defect (todo/0025), fixed on 2026-09-02. Preferences you had saved under the old Ack Expired row were migrated automatically; Assignment and Mention were dropped, because there was never anything for them to do.

The server now rejects an unknown key outright rather than storing it, and a test ties this page's list to the keys the engine reads, so the two cannot drift apart again.

Digest Mode

Mode	Intent
Immediate	Notify as soon as events arrive
Hourly digest	Batch into an hourly summary
Daily digest	Batch into a daily summary
Off	No notifications

Currently stored only, per the table above. In particular, "Off" does not stop notifications. If you need to actually stop being paged, use a silence or change the routing policy — those are enforced.

Quiet Hours

A recurring window — active days, start and end time in 24-hour form, and a timezone — during which non-critical notifications are intended to be held until the window ends, with critical alerts always delivered immediately.

Also stored only. A quiet-hours window configured today suppresses nothing.

The window may cross midnight (22:00 to 08:00 is a normal setting), and the timezone list is a fixed set of common IANA zones.

The values are saved and read back to repopulate this page, but nothing *interprets* them — not the times, not the days, not the timezone. So there is no "empty timezone means UTC" behaviour to rely on. Whatever these fields end up meaning will be decided when the feature is implemented.

Saving

Save Preferences writes all three sections at once. You must be signed in — the page says "Log in to save preferences" otherwise, since preferences are keyed to your user ID.

If saving fails, the page shows the server's error as-is. Treat it as a genuine server problem and check with whoever runs your ObserveKit instance.