Skip to main content

Notification Delivery

A detection that fires but never reaches anyone is indistinguishable, operationally, from a detection that never fired. This page covers the chain between a rule matching and a human seeing the message — the rule, the action behind it, the endpoint configuration, and the downstream service that has to accept the delivery — and how to find which link broke. As with the rest of this section, work down the chain in order.

The Delivery Chain​

An ordered checklist mirroring the layer method, each item linking to its section:

  1. The event or ticket exists.
  2. The rule matched it.
  3. The rule is wired to an action.
  4. The action executes without error.
  5. The endpoint is configured and reachable.
  6. The downstream service accepts and displays the message.

Endpoint Configuration​

Where Endpoints Are Configured​

Endpoints live on Platform → Administration → Notifications (/platform/notifications), titled Platform Notifications on screen. An Endpoints / Rules tab selector sits on the left — Endpoints is shown by default — and two round add-endpoint icon buttons, an envelope and a Slack mark, sit on the right. Each configured endpoint appears as a card whose body lists its properties: Type, the FPL Action that sends the notification, and the delivery target (for an Email endpoint, the recipient address shown as a tag).

Platform Notifications page with Endpoints tab, add-endpoint icons, and an endpoint card

Correcting an endpoint is done by clicking the card's body, which opens the Edit Notification Endpoint dialog pre-filled with its current values. Type is read-only; the name, the FPL action, and the delivery configuration can all be changed and saved in place. This is the fix path for a wrong recipient, a stale channel name, or an endpoint bound to the wrong action — the endpoint does not have to be deleted and rebuilt.

Edit Notification Endpoint dialog pre-filled with an Email endpoint's name, FPL action, and recipient

The ... button in a card's header opens a separate options menu offering a single choice — Delete — behind a confirmation dialog. Because the edit action lives on the card body rather than in that menu, it is easy to conclude the endpoint is read-only and rebuild it unnecessarily.

Endpoint Type Checks​

Email​

An Email endpoint is defined by a Name, a Type fixed to Email, a required FPL Action, and an Email Configurations section holding To (required) and CC. Check the To list before anything downstream — a recipient dropped during a team change looks identical to a delivery failure. Spam quarantine on the receiving side is the single most common cause of "email notifications stopped".

Add Notification Endpoint dialog for an Email endpoint

Slack​

A Slack endpoint is defined by a Name, a Type fixed to Slack, a required FPL Action, and a Slack Configurations section holding Integration — a drop-down of the configured Slack integrations — and Channel, a free-text field. Because Channel is typed rather than picked, a renamed or archived channel leaves the endpoint looking correct while nothing is delivered. Check too that the credential is still valid and the app still installed in the workspace — see Slack Integration.

Add Notification Endpoint dialog for a Slack endpoint

Endpoint Rules​

The Rules tab determines which notifications go to which endpoint. Switch to it from the Endpoints / Rules selector on the left of the header; the two round add-endpoint icons are replaced by an Add Notification Rule button, and an instance with nothing configured reads No rules configured.

Rules tab showing the No rules configured message and an Add Notification Rule button

A rule has three required parts — a Name, the Patterns that trigger it, and the Endpoints it delivers to. All three matter to this diagnosis:

  • No rule at all. A correctly configured endpoint with nothing pointing at it delivers nothing. No rules configured on this tab is the whole answer to "the endpoint looks fine but nothing arrives" — check here before touching the endpoint or the downstream service.
  • Patterns that no longer match. A rule whose patterns stopped matching sends nothing and reports no error anywhere. This is the quietest failure mode in the chain: nothing is broken, so nothing is logged.
  • The wrong endpoint selected. Endpoints is a multi-select, so a rule can be delivering correctly to one destination while the one being watched was never in the list.

Add Notification Rule dialog with Name, Patterns, and Endpoints fields

Compare the rule's Patterns against what the source actually produces now, not against what it produced when the rule was written — a parser or normalization change on the ingest side is a common reason a pattern silently stops matching.