Notification preferences: what reaches you, and how
The settings that decide what gets sent, who receives it, when it waits until morning — and an honest list of which channels actually deliver today.
Your organisation has one set of notification preferences. They decide what is worth sending, who it goes to, and whether it waits until morning. This article is about those settings — what each does, what it is set to before you touch it, and which are worth changing. If your question is which channels exist and how a message is routed, that is Where notifications go; this article is the dial rather than the pipe.
It also contains an unflattering section naming the channels that are configuration without a delivery path today. If you are about to rely on one, read that first.
What you get before you change anything
There are defaults, they are deliberate, and for most small firms they are the right answer. If your organisation has never opened this page, these are in force.
| Setting | Default | Why |
|---|---|---|
| On | It is the one channel that works without you already running something else. | |
| Recipients | Your administrators, looked up at the moment of sending | Nothing to type, and changing who administers the organisation changes who gets told without anybody remembering to update a list. |
| Minimum severity | 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 gets skimmed past. |
| Quiet hours | Off | Deciding unasked that some of your findings can wait is not our decision to make. |
| Quiet window if you turn it on | 22:00 to 06:00 UTC | Whole hours, in UTC. Not your local time — see the caution below. |
| Notify on auto-closed findings | Off | The single most important default here. It is what makes your alert count fall rather than rise when you switch notifications on. |
| Deduplication window | 60 minutes | Repeats of the same thing collapse into one message with a count. |
| Escalate after | 30 minutes | How long something that needs a person may sit unacknowledged before we chase. |
| Escalation recipients | None set | Falls back to the same administrators. |
An organisation with no preferences record is not an error state. The defaults apply, and the console can honestly say you are on the recommended settings rather than pretending you configured them.
The severity floor
The floor is the single most consequential setting. Anything below it is recorded and visible in the console, and not sent. The five values, worst first, are critical, high, medium, low and info; a floor of info means everything is sent, which in a real estate is a great deal.
Raising the floor to critical is what people reach for when the volume becomes annoying, and it is usually the wrong fix. The cause is almost always a noisy detection rule, which is a defect in our content rather than a fact you have to live with. Send it to us. A floor set to critical is quiet in the same way an unplugged phone is quiet.
If you set a value the platform does not recognise, you will see this, and it lists the accepted values in the message rather than making you find them:
HTTP/1.1 400 Bad Request
min_severity must be one of critical, high, medium, low, infoQuiet hours, and the one thing that ignores them
Quiet hours defer; they do not drop. A notification raised inside the window is held and delivered when the window ends, with the reason recorded on it. Nothing is silently discarded, so 'why did I not hear about this until seven in the morning' has an answer.
Who receives it
Leaving the recipient list empty is the recommended setting. With nobody explicitly listed, the platform looks up the holders of the administrator and owner roles at the moment of sending, up to 25 addresses — so an administrator handover does not silently orphan your alerts.
If no administrator role is assigned to anybody, the platform falls back to up to five active members rather than going silent — the worst possible outcome for an organisation mid-onboarding, which is exactly when this is most likely. If there is genuinely nobody with an address, the failure is explicit rather than quiet.
If you set explicit recipients, addresses are validated strictly — an outbound control as much as a check on your typing:
recipient addresses must not contain whitespace, quotes or separators: <address>
not a valid email address: <address>
email address is too long
at most 25 recipientsDistribution lists work, and are usually the better answer: the list outlives the person.
Who can change it
Reading the preferences and changing them are split deliberately. A viewer may confirm that alerting is switched on; silencing the platform's only route to a human is an administrative act. If somebody reports that the settings page is read-only for them, that is the split working. Who can see and do what has the full picture.
Updates are partial. Sending a change to one setting leaves the others as they were, which matters more than it sounds: a body that omitted the severity floor and reset it to info would turn a small adjustment into an alert storm.
Which channels actually deliver today
This is the honest section. Being able to configure a destination and having a message arrive at it are different claims, and the table below separates them.
| Channel | State | What that means for you |
|---|---|---|
| Works | The zero-config default and the one that matters. It depends on a mail relay being configured on the deployment; where that is missing the channel is unavailable and the platform says so loudly at start-up rather than failing quietly. | |
| Slack | Works | Bot token or incoming webhook. |
| PagerDuty | Works | Events API. The right choice if you already carry a rota. |
| Signed webhook | Works | HMAC-signed JSON to an endpoint of yours, for feeding another system. |
| Microsoft Teams | Beta | Messages are sent, but the health check cannot prove delivery — so a working configuration and a broken one look the same until somebody notices the silence. |
| Jira and ServiceNow | Beta | An issue or incident is created. Nothing closes it when the alert resolves, so the queue on that side will accumulate unless somebody tidies it. |
| Push to an Android phone | Works where configured | Real delivery through Firebase where the deployment has credentials. |
| Push to an iPhone | Does not deliver | The Apple sender exists in the codebase but is never connected. A registered iPhone receives nothing, and — this is the part to notice — the delivery record is still marked as sent. Do not count on a phone buzzing. |
Proving it can actually reach you
Two controls answer the only question that matters, which is whether a real message would arrive.
Ask who would be told
The routes view answers 'who would be told if something happened in the next minute', listing each route with its channel and whether it is enabled, and no secrets. An empty list is a first-class answer rather than an error — it is the answer to 'why were we never told?'
Send a real test
The test enqueues a genuine notification down the genuine path rather than poking a connector directly, because 'the token is valid' and 'a message arrives' are different claims and only the second is what you are asking. It is marked as needing a person, so it bypasses your severity floor and quiet hours, and carries a random marker so two tests in a row are not deduplicated — which would look exactly like the second one failing.
Expect it within a minute
The response is immediate and reads:
{"status":"queued","detail":"A test notification has been queued. It is delivered by the worker, normally within a minute."}The message itself is titled Qorionix notification test and its body says: This is a test. If you are reading it, Qorionix can reach you when something real happens.If nothing arrives, check the channel before the settings
The likeliest causes, in order: an iPhone, a Teams destination failing silently, or a deployment without a mail relay. Then check the severity floor.
Acknowledging, and being chased
Anything that needs a person and is still unacknowledged after your escalation interval produces a second notification titled Still waiting: followed by the original title. It cannot produce a third. The reasoning is worth repeating: the finding that most alerts are never addressed is not fixed by sending the first message more loudly, but by noticing that it did not land and telling somebody else.
Acknowledgement tracks whether the work was done rather than whether somebody clicked our button. An alert leaving the open state, a pending approval being answered, or a decision being overridden all count automatically. Acknowledging twice returns no unacknowledged notification with that id, which is harmless.
What to do next
- Send a test today rather than discovering the answer during an incident.
- Leave the recipient list empty and keep your administrator roles accurate instead.
- Read Where notifications go if you want a second channel alongside email.
- If a rule is generating volume you cannot live with, send it to us rather than raising the floor. How to get help says what to include.