Notifications

The bell in the top bar is your in-product record of everything Enori has told you — and the notification centre behind it is where the older ones live.

What is the notification centre?

Every time Enori observes something worth telling you about — a monitor going down, a certificate about to expire, a teammate inviting you to a team, a failed payment — it writes a notification to your account. Those notifications appear in the bell in the top-right of the dashboard, newest first, with a red badge showing how many you haven't read.

The bell holds the 20 most recent. Everything older lives in the notification centre at /dashboard/notifications, reached from the View all notifications link at the bottom of the bell.

Example: "I was away over the weekend. On Monday the bell shows 9+ — I open it, see the API went down Saturday night and recovered eight minutes later, and click through to the monitor to read the incident."

Notifications are per-user and private. Nobody else on your team sees yours, and you never see theirs — when something happens on a shared monitor, each person gets their own copy.

Notifications are not your alerts

This is the single most important thing to understand about this page, so it's worth being blunt:

They are separate systems. Consequences worth knowing:

• The bell is not a delivery channel. If you want to be told about downtime while you're away from the dashboard, you must configure a real alert channel. An unread bell badge doesn't page anyone.
• Configuring a channel doesn't change the bell, and dismissing something in the bell doesn't stop or retract a delivery.
• A monitor with no alert channels still produces in-app notifications for status changes. The alert toggles govern delivery, not the in-product record — so a monitor you deliberately kept quiet will still show its up/down history in the bell.

Set up delivery channels first, and treat the bell as the catch-up surface.

When you'll see a notification

Grouped by what they're about. This is the complete set Enori writes today.

Monitor health

Domain

Emitted for Domain monitors and for the domain-expiry signal on Website monitors: expiring, expired, registrar lock removed, registrar changed, nameservers changed. The last three are hijack early-warnings — they mean something changed at your registrar that you probably didn't do.

SLOs

Fast burn, slow burn, and error budget exhausted — see Service Level Objectives for what burn rate means and how to tune the thresholds.

Browser monitors

Auto-healed a step — a selector in a browser check was updated automatically to keep the check passing. Worth reviewing, and revertible from the monitor.

Team

Team invitation, member joined, member left, removed from team, role changed, ownership transferred.

A team invitation is the one notification you can act on directly in the bell — it shows Accept and Decline buttons inline while it's unread.

Billing

Payment failed, trial ending soon, monitors paused due to plan change. These have no equivalent anywhere else in the product, which is exactly why the bell matters — a failed payment quietly sitting unread is how monitoring stops.

Traces

Quota warning and quota exhausted for your distributed traces ingest allowance.

Alert delivery

Alert delivery failed — Enori tried to send an alert through one of your channels, retried three times, and gave up. Almost always a channel configuration problem: a revoked Slack token, a dead webhook URL, a bounced address. Click it to go to your notification settings.

This one deserves attention when it appears. It means an alert you were counting on did not reach you.

What the bell does

Screenshot: the bell dropdown open, showing a mix of read and unread rows, with the header actions visible.

Unread rows are visually distinct — brighter text and a cyan bar down the left edge. Read ones fade back.

It updates live. A new notification appears in the bell the moment it happens, with a brief badge pulse. You don't need to refresh, and Enori doesn't poll in the background.

The notification centre

/dashboard/notifications is the full history. It isn't in the sidebar — you reach it from the bell.

Screenshot: the notification centre with the All / Unread filter, several rows, and the Load more button.

What it adds over the bell:

• The whole history, not just 20. Rows load 25 at a time — press Load more at the bottom for the next page. When there's nothing left, the button disappears.
• An All / Unread filter. The Unread tab carries the unread count.
• Real counts in the header: "3 unread of 47 total".
• More context per row — the monitor name and team name are shown alongside the timestamp.
• The same Mark all read and Clear all actions.

Timestamps are relative for the first week (just now, 12m ago, 5h ago, Yesterday, 3d ago) and switch to a calendar date after that.

Where clicking takes you

Most notifications are a shortcut into the thing they're about.

A handful have no sensible destination — for example a monitor-scoped notification whose monitor has since been deleted. Those rows still read and dismiss normally; they just don't navigate anywhere.

How long notifications are kept

Notifications expire automatically, so the bell reflects what's currently relevant instead of your entire account history. Retention depends on the type:

The short window on up/down is deliberate: those are the highest-volume notifications, and a two-week-old "recovered" is noise. The events themselves are not deleted — your incident history, audit log, and timeline keep the durable record. Notification expiry only clears the bell.

Expired notifications are removed once a day. A notification that has passed its window may still appear briefly until the next sweep runs.

Notifications and teams

When a monitor is shared with a team, a notification about it is written once per person: you (the owner) plus every member of every team it's shared with. Each copy is independent — you marking yours read doesn't change anyone else's badge.

Team-lifecycle notifications skip the person who caused them. If you invite someone, you don't get a "member joined" notification about your own action; everyone else does.

FAQ

Can I turn off some notification types and keep others?

No — not today. There is no per-type mute for in-app notifications. Every type listed above is written to your bell when the event occurs.

What you can control:

• Alert delivery is fully configurable per monitor and per channel on the Alerts page — that's where you reduce actual noise.
• Maintenance windows suppress monitor status notifications entirely for their duration, so planned work doesn't fill your bell.
• Failure thresholds on a monitor mean a single blip doesn't produce a "Down" notification at all.
• Dismiss and Clear all empty the bell whenever you want, and everything expires on its own within 7–30 days.

Do notifications make a sound, or show a desktop pop-up?

No. There's no sound and no browser or desktop push. The bell badge updates silently and live. If you need to be interrupted, use an alert channel.

Is there an email digest of my in-app notifications?

No. In-app notifications stay in-app. The account-level email toggles in Settings → Notifications control downtime/recovery alert emails and the weekly summary — they're a separate mechanism, not a mirror of the bell.

I turned alerts off for a monitor but it still shows up in the bell. Is that a bug?

No, that's intended. Alert toggles control delivery; the bell records what happened. If you don't want to see a monitor's status at all, pause the monitor.

Does deleting a monitor delete its notifications?

No. They're your record of what happened, they only carry the monitor's name, and they expire on their own schedule.

Are notifications included in my data export?

Yes — a GDPR export from Settings → Security includes your notifications. Deleting your account deletes them.

Can I read notifications through the API?

Yes. /api/notifications supports listing, unread counts, mark-read, and delete, using API keys scoped to notifications:read and notifications:write — see the API reference. One deliberate difference: a team invitation's acceptance token is never returned to an API-key caller, only to your signed-in browser session. Accept invitations from the bell.

Why do I have several notifications for the same incident?

A monitor going down and later recovering are two separate events, so two notifications. If the monitor is shared, you may also see related sharing or team notifications. The bell is a chronological log, not a deduplicated incident view — for the incident view, open the monitor.

Troubleshooting

I'm not seeing notifications at all

Work through these in order:

1. Check the notification centre, not just the bell. If rows are there but the bell looked empty, you were probably looking at a stale tab — reopening the bell refreshes it.
2. Confirm the event actually happened. Open the monitor and look at its recent checks. If a monitor never left "Up", there's nothing to notify about.
3. Check for an active maintenance window on that monitor — status notifications are suppressed while one is running.
4. Check the monitor's failure threshold. If it's set to 3, a single failed check will never produce a "Down" notification.
5. You may have cleared them. Clear all is permanent, and it's easy to hit while catching up.
6. They may have expired — 7 days for up/down, 14 for SSL/domain/SLO, 30 for everything else.

The badge shows a number but the list looks empty

The badge counts unread notifications; the bell shows the 20 most recent regardless of read state. If you have more than 20 and the unread ones are older, they'll be in the notification centre, not the dropdown — open View all notifications and switch to the Unread filter.

The badge is stuck and won't clear

Click Mark all read from the notification centre (its header shows real unread/total counts, so you can confirm the number actually drops). If it doesn't move, reload the page — the count is fetched fresh on load. A badge that reappears immediately usually means new notifications really are arriving; check the Unread filter to see which.

I see "Couldn't load your notifications"

That's a connection or API problem, not an empty inbox — Enori deliberately distinguishes the two so an outage never looks like "you have nothing". Reopen the bell (or refresh the page) to retry. If it persists, check status.enori.io or contact support.

I got "Alert delivery failed" — what do I do?

Enori couldn't reach one of your alert channels after three attempts. Click the notification to go to your notification settings, then open the Alerts page and re-test the affected channel. Common causes: a revoked Slack or Teams token, a webhook endpoint that's returning errors, or an email address that's bouncing. Until you fix it, alerts through that channel are not reaching you.

Clicking a notification doesn't go anywhere

Some notifications have no destination — most often because the monitor or team they referenced has been deleted. The row still marks as read and dismisses normally.

Related documentation

• Settings — account email toggles, GDPR export, API keys and scopes
• Service Level Objectives — what fast burn, slow burn, and budget exhausted mean
• Distributed Traces — trace quota and what happens when it's exhausted
• Audit Log — the durable record of who changed what
• Timeline — every event across every monitor on one calendar
• API Reference — reading and clearing notifications programmatically

Last updated: 2026-07-26. Feedback or corrections: support@enori.io