Where alerts land

A migration programme runs for quarters, not minutes. Most of what AutoPQC learns is not urgent, and treating it as urgent is how a team stops reading anything we send. The operating principle here is narrow enough to state in one line: an alert must name an action, an owner and a deadline, or it should not be an alert.

#Alert or digest

Two channels with two different jobs. Sorting an event into the right one is the whole discipline, and getting it wrong in the generous direction is the more common failure.

• Alert. Something changed that someone must decide about within hours or days. A previously unseen high-tier finding on a production asset. A discovery run that failed and left a scope unassessed. A credential expiring inside a week. Each of these has a named next step.
• Digest. Everything that is true, useful and not time-sensitive. Score movement, counts by tier, newly discovered assets that landed in a low tier, remediation progress against a wave. A weekly read, not an interrupt.
• Neither. Routine run completions where nothing changed. A re-scan that confirmed what yesterday's scan already said is not news. Silence on a quiet estate is a feature.

#Severity routing

Routing follows the risk tier attached to the event, described in What the risk tiers mean. The tier decides the channel and the timing; it does not decide the recipient, which follows the role model.

The last row is easy to overlook and matters more than it looks. If we change the published scoring method, your numbers can move without your estate changing. That is an alert, not a footnote, and the reasoning is documented under How the method is versioned.

Recipients are derived from role grants rather than a separate subscription list, which removes a class of quiet failure. Nobody can be alerted about a workspace they cannot read, and nobody who can act on a critical finding is left off a distribution list because an administrator forgot to add them. The consequence is worth stating: changing a person's role changes what they are told. Removing someone from a workspace stops their notifications in the same action.

#Destinations

Two destinations work today. A third is planned. We would rather ship two reliable paths than five that mostly work.

Email

The default for both alerts and digests. Delivered to the address carried in a member's identity assertion, or to a nominated distribution address for digests. Content is deliberately thin: what happened, which workspace, which asset class, and a link back. We do not put finding detail in an email body.

Webhook

The path for anything that should reach a pager, an incident tool or an internal router. You receive a signed event and apply your own routing logic — critical to on-call, high to a team channel, everything else discarded. Delivery, signing and retry semantics are in API and automation surfaces.

Chat

Roadmap. Direct delivery into a chat workspace is not generally available. Until it ships, a webhook plus your existing chat gateway does the same job and keeps the routing logic where your team can read it. [PLACEHOLDER: chat delivery target date]

#Quiet hours and de-duplication

The two mechanisms that keep a channel readable. Both are opinionated, because the alternative is a configuration surface larger than the feature.

1. 01Quiet hours. A window per workspace during which non-critical alerts are held and delivered when the window closes. Critical events ignore quiet hours entirely; a window that suppresses everything is an outage you configured yourself.
2. 02De-duplication. Repeated occurrences of the same condition on the same asset collapse into one alert with a count, within a rolling window. A misconfigured load balancer presenting the same weak cipher on forty endpoints is one problem, not forty pages.
3. 03Change-only triggering. An alert fires on the transition into a state, not on every observation of it. An asset that has been high-tier for three weeks does not re-alert on every sweep. It appears in the digest until it is resolved.
4. 04Resolution notices. When an alerted condition clears, the closing notice goes to the same destination. An alert channel that only ever opens threads teaches people that nothing ever gets fixed.

Quiet-hour windows, de-duplication windows and thresholds are set with our team during onboarding rather than in a self-service settings page. [PLACEHOLDER: self-service notification settings target date] The defaults are conservative on purpose: fewer alerts, each of which has earned its place.

#Tuning a channel that has gone quiet

Alert fatigue is measurable. If nobody has clicked through from an alert in a month, the channel has failed regardless of how correct each individual message was. The fix is subtraction.

The opposite failure is quieter and more dangerous. A channel that produces nothing for a quarter is either evidence of a stable estate or evidence that a rule was scoped down to nothing during a noisy week and never restored. Confirm which by checking the digest against the alert history: a workspace with new high-tier findings in the digest and no alerts against them has a routing problem, not a calm estate.

• Narrow the scope before you narrow the severity. Alerting on production only is usually a bigger improvement than raising the tier threshold, because it removes noise without hiding real risk.
• Move anything with a deadline measured in weeks into the digest. Deadlines that far out belong on a plan, not in an interrupt.
• Give every alert class a named owner. An alert routed to a distribution list with no owner is read by nobody, which is the same as not sending it.
• Review the routing table once a quarter alongside your remediation waves. Sequencing changes what deserves attention — see Sequencing a migration.