Where notifications go

This article answers two questions: how will Qorionix tell you that something happened, and — the one people actually ask, usually afterwards — why were you not told about something else. It is written for the person who has to be reachable, and it is explicit about which destinations work today and which are built but not yet reachable through the product.

What happens if you configure nothing

The absence of any notification settings is a fully supported state, not a misconfiguration — the whole premise of the product is a customer with no security team and no appetite for setup. A tenant that has never touched these settings gets an opinionated default rather than a permissive one:

Email is on, to your administrators

Recipients are resolved when the message is sent, from whoever currently holds the admin or owner role in your organisation, up to 25 addresses. Nothing to type — and changing who administers the organisation changes who gets paged without anyone remembering to. If no admin role has been assigned yet, it falls back to any active member rather than going silent.

The severity floor is high

Medium and low findings are real work, but they are console work. Mailing them is how an inbox becomes noise and the next critical is skimmed past.

Auto-closed false positives notify nobody

This is the single most important default. It is what makes your alert count fall rather than rise when notifications are switched on. Forwarding an alert the platform has already investigated and dismissed rebuilds the problem you bought the tool to fix.

Quiet hours are off

Turning them on for you would mean deciding, on your behalf, that some findings can wait — and we do not know your staffing. Once you turn them on they defer rather than drop.

Repeats collapse for 60 minutes, and unacted work escalates after 30

The same condition reported repeatedly is one notification, not six. Anything blocked on a person that nobody has acted on is re-sent after 30 minutes with the title prefixed Still waiting:.

The interface reports whether these are your choices or ours, so onboarding can honestly say using recommended settings rather than implying you picked them.

How the platform decides to tell you

Routing is done on two axes rather than one: how bad the finding would be if it were real, and what Sentinel-Q concluded about whether it is real and whether a person still has to do something. The rules are applied in this order, and the order is the point.

1. Anything blocked on a person always goes. A response action waiting for approval, an escalate-to-human verdict, a recorded escalation reason. These ignore the severity floor and break quiet hours, because an approval that arrives after the approver wakes up is a delay, not an approval.
2. An auto-closed false positive notifies nobody. That is the platform doing its job.
3. Everything else must clear the severity floor, which defaults to high.
4. Repeats inside the deduplication window are collapsed, grouped by organisation, module, detection and the host or account involved — the same grouping the platform uses to fold related signals into one incident. When several are collapsed, the message carries an occurrences count so that deduplication does not look like lost alerts.
5. Quiet hours defer, they do not drop. Critical severity and anything blocked on a person break through anyway. A product that can be configured to sit on a ransomware detection until 07:00 is not a security product.
6. Unacknowledged human-required work escalates. Firing once into a channel nobody reads is indistinguishable from not firing.

Every one of those decisions is written down against the notification, including the decision not to send. The suppression reason is one of auto_closed_false_positive, below_severity_floor, duplicate_within_window, no_destination_configured or no_route_matched. This exists so that why was I not paged? has an answer — a question that is simply unanswerable in a system that only records what it did send.

Acknowledgement tracks whether the work was done, not whether you clicked our button. If the approver approved the ticket in the console, or the alert left the open state, the escalation ladder stops on its own.

Immediate, deferred — and no digest

There is no daily email digest. Notifications can be queued, waiting to retry, sent, suppressed with a reason, or failed. A queued notification has not yet reached its destination. Check its delivery history before assuming someone has been told.

Email notifications sharing a sender are spaced at least one minute apart. If the email provider temporarily refuses a message, the sender waits 30 minutes before another attempt. The notification stays queued for retry, including after a service restart; waiting for a slot does not count as a failed attempt. Other delivery failures can still reach the five-attempt limit. Credential-renewal notices remain retryable until their condition is resolved.

When email is waiting but another destination has accepted the notification, later retries skip destinations with a saved delivery receipt. A provider accepting a message does not prove it reached a person's inbox. If the service stops after sending but before saving its receipt, a duplicate remains possible. Earlier failed notifications are not automatically resent by this pacing change.

The channels, and which of them can reach you

The six non-email targets are not stubs. They are real clients with real health checks, wrapped so that a Slack destination which has stopped delivering is surfaced by exactly the same machinery as a Microsoft Entra ID sync that has stopped syncing. What is missing is the small piece in front of them: the record that says send notifications matching this rule to this configured Slack instance. The table for it exists and the dispatcher reads it; nothing in the product writes to it. Configuring a Slack connector, on its own, creates an integration — not a destination.

If a route does exist, it carries its own filter on top of the tenant-wide rules: a minimum severity, an optional list of modules, an optional list of detection categories, and its own quiet window that critical severity always breaks. Every delivery attempt is recorded per destination with its outcome, so we never get alerts in the operations channel is a question with a specific answer rather than a general suspicion.

Push notifications and the mobile app

There is a mobile application in the repository — an Expo build for iOS and Android that shows the Sentinel-Q decision feed and lets an approver accept or reject a live-response ticket. There is a device registration endpoint, a queue for outbound push, and a working Firebase client for Android and an Apple Push Notification client for iOS.

None of that adds up to a shipping product yet, and this is the honest position:

• The app is not published to either store. There is no build for you to install.
• The iOS sender is not wired in the running service at all — the Apple client exists in the codebase but the deployed configuration always uses a sender that writes the notification to a log instead of sending it. The queue then records the row as sent, so the platform's own push history will show a delivery that never left the building.
• The Android sender only becomes real if a Firebase service account has been provisioned on the deployment. Without one, it also logs rather than sends.
• Push is fed only by Sentinel-Q triage decisions, on its own filters. It is a separate pipeline from the notification preferences described in this article, and nothing you set here affects it.

Changing the settings, and proving it works

1. 1

   Read what is in force before changing it

   The preferences endpoint returns your current policy and an is_default flag telling you whether anyone has ever changed it. Reading requires integration:notifications read; changing it requires write, because silencing the platform's only route to a human is an operator act rather than a view.

2. 2

   Change one thing at a time

   An update starts from what is already in force, so omitting a field leaves it alone rather than resetting it. That matters most for the severity floor: a body that reset it to info would turn a small tweak into an alert storm.

3. 3

   Know the validation messages

   min_severity must be one of critical, high, medium, low, info for an unknown severity. For recipients: not a valid email address: plus the value, recipient addresses must not contain whitespace, quotes or separators: plus the value, email address is too long, and at most 25 recipients. The separator rule is a security control as much as a validation — these values are used to build mail commands.

4. 4

   See who would actually be told

   The notification routes endpoint lists the destinations that would be used if something happened in the next minute, with no secrets in the response, and reports reachable: false when the list is empty. An empty list is returned as a first-class answer rather than an error, because it is the answer to the question that matters.

5. 5

   Send a real test

   The test endpoint queues a genuine notification down the genuine path rather than pinging a token, because the credentials are valid and a message arrives are different claims and only the second one is what you are asking. It is marked as requiring a human so your own severity floor and quiet hours cannot silently swallow it. You get back HTTP 202 and A test notification has been queued. It is delivered by the worker, normally within a minute.

What to do next

• Send yourself a test notification today, before you need one. It is the only way to find out whether your deployment has mail configured.
• Outbound webhooks — if you want events in your own system rather than a chat channel, this is the route that is fully self-service.
• Alert severity and triage — what the severity levels mean before you move the floor.
• When to bring in a human — the findings that will always break through whatever you set here.