Skip to content

Agent-Gated Pager Escalation: Judged Criticality on the Notification Destination

An agent grading alerts before the pager belongs on one destination, beside an unfiltered one, and must escalate whatever it cannot judge.

The gate is a property of the notification destination, not of the alert rule. Vercel shipped it that way: "With validation enabled for a webhook destination, only alerts Agent classifies as Critical are sent to it" (Vercel changelog, 28 October 2026). You create or link a webhook destination for the paging system, then select Critical Only beside it. The same control is scriptable through vercel monitors notifications with --critical-only when linking or updating that destination.

Two filters at two layers

A monitor already carries a declared severity floor. Vercel's monitor schema exposes matchMinimumSeverityLevel, set to values like high or critical in the CLI reference's own examples (Vercel CLI: monitors). That filter is a number you write down and can diff.

The agent gate sits one layer lower, between the firing monitor and one of its destinations. Vercel describes the judgment as impact assessment over telemetry: "Agent checks logs and metrics to assess impact. For example, it can identify health-check errors that don't affect customers or confirm sustained 5xx errors affecting checkout requests" (changelog). Per-monitor context can be added to steer that investigation. Keeping the two filters separate is what preserves the first one: the declared threshold stays reviewable, and the judged verdict reaches only the destinations you routed through it.

Three conditions before you enable it

Everywhere else an agent enters incident work, a wrong answer costs a human extra reading. Here it means nobody is woken, so the pattern only holds under three conditions the vendor setting does not enforce for you.

Ambiguity escalates

The gate must page when it cannot establish impact. This is a proposed fail-open policy, not behavior the vendor documents or a benchmark measures. CORTEX, a multi-agent alert-triage architecture, uses a different rule for its own workflows: "CORTEX adopts a conservative decision policy: if any workflow escalates, the overall verdict is actionable" (arXiv:2510.00311v1).

An unfiltered destination runs beside the gated one

Because the setting is per destination, you can route a paging webhook through the agent and leave a second destination unfiltered. Read the difference between the two streams before you trust the gate. A suppression gate's mistakes are invisible from the paging side.

The telemetry carries impact signal

The gate reads logs and metrics, so it inherits whatever a service failed to emit. On SIR-Bench, a benchmark of simulated cloud security incidents, one agent's false-positive rejection ranged from 47.8% to 82.7% across four attack categories, and its authors tie the weakest category's showing to "limited telemetry for instance-level activity without additional logging sources" (arXiv:2604.12040v1).

Why it works

Static filters can distinguish routes; this gate adds telemetry-based impact assessment.

CORTEX measures a related substitution in security operations. Grounding adjudication in tool-fetched evidence across role-split agents, rather than one end-to-end model pass, cut the false-positive rate by 10.7 points, from 24.9% to 14.2%, and raised actionable-class F1 from 0.66 to 0.78 against the best single-agent baseline on that paper's own SOC dataset (arXiv:2510.00311v1). Those figures cover security alerts in one benchmark, not web monitors, and the paper's results table publishes no recall column, so it quantifies the noise it removed and not the alerts it missed.

When this backfires

  • Minutes matter. Judgment is not free on the page path. In that same SOC setting, CORTEX's median end-to-end time per ticket is 152.4 seconds, against 44.6 seconds for its tool-using single-agent baseline (arXiv:2510.00311v1). A gate that is right and slow still extends a checkout outage.
  • The dismissal direction is the weaker one. SIR-Bench weights recall nine times more heavily than precision, and the second of its two reasons is about model error modes rather than security cost: when an agent wrongly dismisses a real attack, "this more likely reflects hallucination or superficial reasoning", where a wrong escalation typically reflects caution (arXiv:2604.12040v1). A pager gate makes dismissal the agent's routine output.
  • Log lines are semi-trusted input. CORTEX names prompt injection among the sensitivities of agentic systems of this shape (arXiv:2510.00311v1). Where users or attackers influence log content, the gate reads their text to decide whether to wake the defender.
  • Judgment is metered, so alert volume becomes spend. Observability Plus "includes ten Agent investigations per billing cycle, with additional investigations billed separately", and custom monitors cost $0.0035 per GB of data scanned (changelog). Nothing in the changelog says what the gate does when the agent is unavailable, which on the paging path is the question that matters most.

A reasonable team declines this entirely. The notification path is the component whose job is to work when everything else is broken, and a declared threshold is deterministic, replayable, and visible in a diff. Those are real properties to trade away.

Example

Keep the declared floor on the monitor and put the judged verdict on one of two destinations. The monitor definition looks like this:

{
  "type": "built-in",
  "name": "Production server errors",
  "triggers": {
    "mode": "selected",
    "items": [
      { "type": "error_anomaly", "filter": "statusGroup:5xx AND route:/api/*" }
    ]
  },
  "matchMinimumSeverityLevel": "high"
}

Run vercel monitors notifications --help for the subcommands, which the CLI reference points to rather than enumerating (Vercel CLI: monitors). The changelog says to add --critical-only when linking or updating the webhook destination for the pager. Leave a second destination, such as a low-urgency channel, without that flag. Read the gap between the two before you trust the gate.

Key Takeaways

  • The escalation filter is a destination setting, which is what makes it reversible. You change one webhook's configuration, not your alert rules.
  • Run the gated destination beside an unfiltered one. A suppression gate's errors do not appear on the paging side, so the unfiltered stream is your only read on what it dropped.
  • Ambiguity must page. Borrow CORTEX's escalate-on-any synthesis rather than trusting a single confident verdict.
  • No published source measures the miss rate for this use. The two benchmarks here cover security alerts, and one of them reports no recall at all, so budget for discovering your own figure.
  • Per-investigation billing gives a chatty monitor a cost line.
Emerging — single recent source Last reviewed: 2026-10-29