Alert rules and notifications

Alert rules tell ErmisAI to flag a story the moment it matches something your desk cares about. Notifications are where the flag lands. They are two separate screens, with two different audiences.

• Alert rules live on Monitoring, which only the editor-in-chief and managing editor can open.
• Notifications live in Settings → Notifications, and every member of the newsroom can read them.

Who can build rules

Opening Monitoring in the sidebar requires the owner or admin role — the two roles the team screen titles Editor-in-Chief and Managing Editor by default. Members do not see the sidebar item at all. If a member reaches the page some other way, they get a card reading "Monitoring access is restricted" with the line "Monitoring is limited to the editor-in-chief and managing editor."

Members still receive alert notifications in their inbox. They just cannot change the rules that produce them. See Team, roles and permissions.

The Monitoring screen

The page is headed "Monitoring & alerts" with the subheading "Configure watched sources, rule triggers, and delivery behavior." It has four tabs:

A badge in the top right shows the live connection: "Live alerts", "Polling fallback", "Connecting", or "Offline". Alerts still fire when it says Offline — the badge only describes whether this browser tab is receiving them in real time.

Tab selection is not part of the address, so you cannot bookmark or share a link to a specific tab.

Which stories a rule can fire on

A rule is only ever tested against a story that has already cleared one of two bars:

1. It arrived from the pipeline with a Signal score of 85 or above and no sensitive flag, or
2. An editor approved it on the editorial board.

Everything else — anything held for review, anything flagged sensitive, anything below 85 — is invisible to alert rules until an editor approves it. This is deliberate: it stops a rule from paging the desk about material nobody has looked at.

The practical consequence is that alerts are not a wire ticker. A sensitive breaking story will not raise an alert when it lands; it raises one when an editor approves it. Read Confidence, sources and conflicts and Sensitive coverage and editorial limits for what those two signals mean.

Rules are checked when a new story arrives in your feed, when an editor approves a story, when you save a new rule, and on a background sweep roughly every ten minutes. Saving a rule checks it against stories already in your feed, so a new rule can fire immediately.

Monitored sources: the eligibility gate

The Sources tab has two panels. On the left, "Source catalog" — "Click a source to inspect it, then add it to monitored intake." Search by name, region, or category, or filter by tier (All tiers, Wire, Tier 1, Tier 2, Tier 3). Select a row and the add button reads "Monitor" followed by that source's name; with nothing selected it reads "Select a source" and is disabled.

You can only add sources that are already in your newsroom's catalog. To add a feed that is not there, use Settings → Newsroom first — see Choosing and adding sources.

On the right, "Monitored sources" lists what you are watching. Empty, it reads "No monitored sources selected yet." Each row has a "Remove" button, a flags line, and a health line drawn from the last completed feed build:

• "Fetching OK", followed by the article count for the past 24 hours
• "Feed returned no items"
• "Last fetch failed", with the error appended when there is one

The health line only appears once your newsroom's feed has been built at least once, and it drops off every row the moment you add a source. Reload the page to bring it back.

Sources you select in Settings → Newsroom are added to this list automatically. Deselecting them there does not remove them here — you have to press Remove on this screen.

Building a rule

The Rules tab has the form "Create alert rule" on the left and your existing rules on the right.

Press "Save rule". An empty name is rejected with "Rule name is required"; a successful save shows "Alert rule created".

Mode exists but has nothing to choose. The only value is Instant, and the help line under it says so: "Email digest delivery is not configured in this runtime." If a rule from an older configuration is still set to a digest mode, its card shows an amber line: "This legacy rule depends on email digest delivery, which is not configured."

Reading and removing rules

The "Rules" panel lists your rules newest first; empty, it reads "No rules configured yet." Each card shows the name, a "Delete" button, and four lines:

Keywords: earthquake, evacuation
Categories: World
Sources: Any
Mode: instant · Min sources: 2 · Cooldown: 30m · Breaking only: No

Sources prints raw source identifiers rather than the names you picked from, so a rule with a source constraint is harder to read back than one without.

How many rules your plan allows

On Free the Rules tab still renders in full, including the Save rule button. The refusal only appears after you submit, as "Monitoring rules are not available on the current plan." At the cap on a paid plan the message is "Monitoring rule limit reached for the current plan (5)."

Where an alert is delivered

The Delivery channels tab is informational only; there are no controls on it. Two channels work:

• In-app. Always on, for every rule. The card reads "In-app banner" — "Workspace alerts surface in the monitoring stream and notification panel." The alert appears in Alert history and as a notification in every workspace member's inbox.
• Webhook. The card is labelled "Webhook (preview)" — "Alert deliveries go to the webhook endpoint configured in Settings → Integrations." It only fires if a workspace owner has saved an endpoint and a signing secret and switched delivery on. See API keys, webhooks and WordPress.

Email does not work. The card reads "Email digest" — "Email digests are not available yet. Digest-mode rules deliver in-app until email delivery ships." No alert has ever been sent by email and there is no setting that would enable it.

The "Webhook simulator" card is not a simulator. Its text — "Use the integrations workspace to send test webhooks to your endpoint." — is the whole feature. There is no per-rule test fire or dry run anywhere in ErmisAI.

A "Latest delivery failure" card is populated from the live stream, which replays the newsroom's recent failed deliveries when it connects — so the card normally reappears after a reload and can show an older failure rather than a fresh one. It is only absent when the workspace is on the polling fallback, where stream payloads are never applied. The durable record of webhook attempts is "Recent webhook deliveries" in Settings → Integrations.

When a rule stays quiet

Three things suppress an alert that would otherwise fire:

1. Already sent. A given rule fires at most once for a given story on a given channel, ever.
2. Cooldown. After a rule fires, that rule stays quiet for its cooldown window — per rule, not per story. A 30-minute cooldown means a second, different matching story within those 30 minutes raises nothing. Set the cooldown to 0 if you would rather have every match.
3. No eligible story. The monitored-source gate, the plan cap, and the published-or-approved bar above all silently produce zero alerts rather than an error.

If a webhook delivery fails, the alert is retried on the next evaluation pass rather than being written off. The in-app copy is unaffected either way.

Alert history

The Alert history tab lists what fired. Each card shows the rule name and the story headline together — Breaking world wires: Ferry runs aground off Chios — a severity pill, and a detail line:

Story: <story id> · Channel: in-app · Delivered: <date and time>

Severity is derived from the story, never configured on the rule: a breaking story is critical, a sensitive story or one with a Signal score below 80 is warning, everything else is info.

History is capped at 500 entries per newsroom; older entries roll off. There is no acknowledge, snooze, assign, or resolve — an alert is a delivery record, not a task.

The notification inbox

The bell icon — at the foot of the sidebar on a wide screen, in the header on a narrow one — carries an unread count, capped at 99+, and links straight to Settings → Notifications. There is no Notifications item in the main sidebar navigation.

The screen is headed "Notifications" — "In-app alert and operational notifications." It has a live-connection badge ("Live stream", "Polling fallback", "Connecting stream", "Offline"), a "Mark all read" button that is disabled when there is nothing unread, and "Refresh". Empty, the list reads "No notifications yet."

Each entry shows a title, a body, a timestamp, and a type — alert, system, billing, review, note, or publication. Unread entries carry a "Mark read" button; read ones show a "Read" pill.

The inbox merges two streams: things addressed to your newsroom as a whole, and things addressed to you personally.

• Shared with the whole workspace: every triggered alert, rule creation, AI capacity warnings, and integration changes. Every member sees them.
• Personal to you: review submissions and reminders sent to reviewers, review feedback, an article being published, and an article being sent back — plus notes left on a story you own.

Read state is per person. Marking something read never marks it read for a colleague.

Each of those two streams keeps only its 120 most recent entries; older ones roll off. The inbox is a working list, not an archive.

What ErmisAI actually notifies you about

Failed webhook deliveries do not produce a notification. If you rely on webhook alerts, check "Recent webhook deliveries" in Settings → Integrations periodically.

What you cannot do

Stated plainly, so you do not go looking:

• No notification preferences of any kind — no mute, no digest cadence, no per-type or per-channel toggle, no way to change who receives what.
• No email or push notifications. The inbox is in-app only.
• No editing a rule, and no way to pause one without deleting it.
• No All alerts switch on a monitored source; monitored sources only ever raise breaking stories.
• No test fire, dry run, or preview for a rule.
• No acknowledge, assign, or resolve on an alert.
• No per-rule delivery-channel picker. In-app is always on; webhook follows your one workspace webhook configuration.