Why Your On-Call Staff Are Ignoring Alerts: Lessons from Notion’s AI Experiment

Introduction

There’s a fascinating headline making the rounds: Notion is killing its Gmail client because AI agents became too good at handling email. The premise is simple—more than half of users let the bots manage the inbox so effectively that the human interface became redundant. It’s a success story for automation, but for IT operations, it highlights a terrifying parallel.

In the world of IT, we are facing the opposite crisis. Our "bots"—monitoring agents, RMM platforms, and disparate scripts—are generating so much noise that humans are effectively tuning them out. When an on-call sysadmin gets pinged at 3:00 AM for a non-critical CPU spike, a low-disk warning on a decommissioned server, and a flapping network port all within ten minutes, they don't become more efficient. They burn out. They silence the phone. They go back to sleep.

And that is when the real outage happens. Just like Notion users who stopped checking their inbox, your IT team stops checking the alert console. The result? You learn about critical downtime from angry users or client CEOs, not your monitoring stack.

The Problem in Depth: Signal vs. Noise

The Notion article proves that when automation works perfectly, it reduces the need for human intervention. In IT Operations, however, our automation is often broken by design—fragmented across siloed tools that don't talk to each other.

Siloed Architecture Creates Context Deserts

Most MSPs and internal IT departments run a fragmented stack: You might have NinjaOne or Datto for RMM, a separate instance of SolarWinds or Zabbix for infrastructure monitoring, and ServiceNow or Autotask for the helpdesk.

When a Windows Server 2019 host spikes its memory, the RMM sends an alert: "High Memory Usage."

It doesn't tell you that Client A is running a month-end close.
It doesn't tell you that the SQL Service was just restarted by a patch policy.
It doesn't tell you what "normal" looks like for that specific machine.

Without this context, the alert is useless. The on-call engineer has to log in, open three different tabs, and investigate. If this happens five times a night, they stop investigating.

The Real Impact on IT Operations

The cost of this isn't just annoyed technicians. It is measurable business risk:

SLA Misses: If the team is desensitized to noise, a critical down-alert for a primary firewall gets buried in the queue. Resolution times (MTTR) skyrocket.
Staff Turnover: Constant low-value paging is the number one cause of burnout in NOC teams.
Tool Sprawl Fatigue: Managing the connectors and API integrations between your RMM and your monitor becomes a full-time job in itself.

How AlertMonitor Solves This

At AlertMonitor, we took a hard look at the "Notion problem"—how do we make automation work for the human, not against them? We realized alert fatigue isn't a volume problem; it’s a signal quality problem.

Context-Rich Alerting

AlertMonitor doesn't just tell you something is wrong; it tells you exactly what, where, and why. Every alert packet carries full context:

Device Identity: Which server, workstation, or firewall is affected?
Client Context: Which client or department does this belong to?
Delta Analysis: What changed? Did CPU jump 5% or 500%?
Baseline Data: What does "healthy" look like for this specific device?

Intelligent Escalation and Suppression

Unlike standard email alerts that flood your inbox, AlertMonitor uses intelligent escalation policies. If a non-critical alert fires, we don't page the senior architect immediately. We route it intelligently.

More importantly, we respect Maintenance Windows. If your patch management window is active, AlertMonitor automatically suppresses the "Server Reboot" alerts. We correlate events across your stack so that if the RMM initiates a reboot, the Monitoring platform knows not to scream "Host Unreachable." This eliminates the "Cascading Noise" that wakes your team up for nothing.

The Unified Workflow

In the old world, an alert triggered an email, which opened a ticket, which required an RMM login to fix. In AlertMonitor, the workflow is unified:

Detect: Anomaly detected via agent or SNMP.
Enrich: AlertMonitor pulls context from the CMDB and topology map.
Route: On-call tech receives a push notification with the full context.
Resolve: Tech executes the remediation script directly from the AlertMonitor console.

Practical Steps: Killing the Noise Today

You can start fixing your signal-to-noise ratio immediately by implementing context-driven maintenance windows and intelligent pre-checks before you page your staff.

Step 1: Define Maintenance Windows in Your Monitoring

Never patch during production hours without explicitly telling your monitoring tools to go to sleep. Ensure your monitoring tool accepts API calls to toggle maintenance modes.

Step 2: Use Contextual Scripts for Triage

Before paging a human, use a script to validate the state. This mimics the "AI agent" behavior from the Notion article—let the bot do the checking so the human only wakes up if the bot fails.

Here is a PowerShell example that checks a critical service and only reports a failure if specific conditions are met (e.g., the service is down AND it's supposed to be running). This adds the context your monitoring needs.

PowerShell

<#
.SYNOPSIS
    Checks service status with context to prevent false alarms.
.DESCRIPTION
    Returns detailed service info including startup type and status.
    Use this as a pre-script for your monitoring alert.
#>

Param( [Parameter(Mandatory=$true)] [string]$ServiceName )

try { $Service = Get-Service -Name $ServiceName -ErrorAction Stop

Code

# Context: Only alert if the service is stopped but set to Auto
if ($Service.Status -ne 'Running' -and $Service.StartType -eq 'Automatic') {
    Write-Output "CRITICAL: $($ServiceName) is $($Service.Status) but StartType is $($Service.StartType)."
    exit 1
}
elseif ($Service.Status -eq 'Running') {
    Write-Output "OK: $($ServiceName) is running."
    exit 0
}
else {
    Write-Output "WARNING: $($ServiceName) is $($Service.Status) but StartType is $($Service.StartType). No action required."
    exit 0
}

} catch { Write-Output "UNKNOWN: Service $ServiceName not found." exit 2 }

Step 3: Centralize Your Routing

Stop relying on individual email rules. Route all alerts to a single aggregation layer (like AlertMonitor) that can de-dupe and bundle. If the same switch sends 100 "Interface Down" alerts in 10 seconds, your engineer should receive one notification, not one hundred.

Conclusion

Notion proved that when automation works perfectly, humans don't need to check the inbox. In IT Ops, our goal is slightly different: we want our humans to check the "inbox" only when the automation can't handle it. By adding context, suppressing noise during maintenance, and routing intelligently, AlertMonitor ensures that when the pager goes off, it matters.

Stop training your team to ignore alerts. Start giving them the data they need to act fast.

Related Resources

AlertMonitor Alert Management & On-Call Operations AlertMonitor Platform Overview Book a Demo Alert Management & On-Call Operations Resources