71% Now Expect AI to Cut Jobs — Here's How IT Teams Cut 2 A.M. Pages Instead

A new Pew Research Center survey covering 37 countries found that in 34 of them, more people believe AI will destroy jobs than create them over the next 20 years. In the US, 71% of respondents expect fewer jobs. In Sweden, skepticism toward AI jumped nine percentage points in a single year — the largest increase of any country tracked over time — and the worry spans both younger and older respondents.

If you run infrastructure for a living, that fear is not abstract. You have sat through the vendor keynotes. You have watched a demo where an AI copilot triages tickets and quietly wondered which line item on next year's budget is your job.

Here is what the survey does not capture: the IT teams most at risk of burnout are not at risk because AI is coming for them. They are at risk because their current tools are drowning them. The sysadmin who quit your team last quarter did not leave because a model outperformed them. They left because they were woken at 2:14 a.m. for the fourth night in a row by a monitoring tool that cannot tell the difference between a failing RAID array and a scheduled reboot.

AI applied correctly does not replace the on-call technician. It removes the 80% of their night that was never real work: deduplicating alert storms, triaging noise, and manually correlating data across four disconnected tools. That is the thesis behind how we built alert management and on-call operations in AlertMonitor — and it is why teams that adopt signal-quality-first alerting end up more valuable, not more replaceable.

The Real Problem Is Not Headcount. It Is 3,000 Alerts a Week.

Talk to any MSP NOC or internal IT team and you will hear versions of the same story:

• A static-threshold monitoring tool that fires blindly. Nagios, Zabbix, PRTG, or the alerting module bolted onto an RMM like NinjaOne or ConnectWise watches CPU at 90%, disk at 90%, memory at 90%. It does not know that the SQL server hits 92% CPU every night at 1 a.m. for a backup job, or that the C: drive on FS-PROD-02 has grown 6 GB in 48 hours and will be full by Thursday.
• Alert storms that bury root cause. A core switch reboots and 214 alerts arrive in 11 minutes — every downstream server, access point, and printer goes offline on the dashboard. The on-call tech receives 40 pages and has to mentally reconstruct the topology at 3 a.m. to figure out that one device caused all of it.
• Alerts with no context. A disk alert arrives with no device relationship, no trend, no baseline, no owner. Is it the client's file server with 40 GB free, growing slowly? Or the volume that has been filling at 2 GB per hour since noon? The alert treats both identically. The tech has to open three tabs to find out.
• Routing that does not exist. Every alert goes to one email distribution list or one shared phone. No severity-based escalation, no primary/secondary on-call chain, no acknowledgment tracking. Either nobody sees it, or five people see it and each assumes someone else owns it.
• Maintenance windows that are ignored. Patch Tuesday starts at 10 p.m. By 10:40 p.m. the monitoring tool has paged the technician six times for planned reboots and services restarting by design.

Why These Gaps Exist

This is not a training problem. It is architecture. Most IT teams assembled their stack one tool at a time over a decade:

• Monitoring — or the RMM's built-in alerting — was bought separately from the helpdesk. The alerting engine has no idea a ticket already exists for this issue, and the ticketing system has no idea the device has been flapping for three days.
• Legacy monitoring was built around device counters, not services and outcomes. It watches a threshold; it does not understand that the counter is part of a payment-processing workflow finance depends on.
• Nothing shares state. The monitor cannot read patch status. The helpdesk cannot read monitoring history. The technician becomes the integration layer — copying device names, statuses, and timestamps between five browser tabs. That is the actual, unautomated job many teams are paying skilled engineers to do.

What It Costs

Run the arithmetic on your own environment. If your stack generates 3,000 alerts a week and fewer than 2% require action, the other 98% is a tax paid in three currencies:

• Response time. The real signal sits in an inbox between 200 false positives. Median time-to-acknowledge stretches from minutes to an hour or more. The file server that filled up Friday at 6 p.m. is discovered Monday at 8:15 a.m. — by end users who cannot save documents — and lands as ticket #4821 with a 60-hour effective MTTR.
• People. Nobody stays in a role where sleep is interrupted nightly for noise. Replacing a senior sysadmin or NOC tech costs months of ramp-up plus 20–30% of salary in recruiting — and the institutional knowledge about which client's switch flaps every third Thursday walks out with them.
• SLA accuracy. When monitoring data lives in one system and ticket timestamps live in another, your SLA report is a manual CSV merge every month — and every dispute with a client or the business becomes an argument over whose clock was right.

The burnout is not a soft cost. It is the mechanism by which the fear in the Pew survey becomes self-fulfilling: teams that cannot sustain on-call stop trusting their tools, start ignoring alerts, and eventually need fewer of them — not because AI won, but because the noise did.

How AlertMonitor Fixes the Signal, Not Just the Volume

AlertMonitor was designed around one insight: alert fatigue is not a volume problem — it is a signal quality problem. Cutting alerts by hiding them just moves the risk somewhere else. The fix is making every alert worth reading.

Every alert carries full context. Device, client, what changed, and what healthy looks like. A disk alert on FS-PROD-02 arrives showing the volume, the growth trend, the projected time-to-full, and the client it belongs to. The tech triages from the notification itself — before opening a single tab.

Smart deduplication collapses storms. When the core switch reboots, the 214 downstream offline alerts are correlated into one incident rooted at the switch. One page. One acknowledgment. The tech fixes the cause instead of dismissing 214 symptoms.

Multi-level escalation policies route reality. Severity-, client-, and time-of-day-aware routing: business-hours warnings go to the service desk queue; after-hours criticals page the primary on-call, escalate to secondary after five minutes unacknowledged, then to the IT manager. Every page has an owner and a clock.

Maintenance window suppression. Patch schedules registered in the platform suppress expected reboot and service alerts automatically. Your Patch Tuesday run generates zero 2 a.m. pages — and if a server fails to come back after its window closes, that alert still fires, because the window ended.

The loop closes in one place. A meaningful alert auto-creates a helpdesk ticket linked to the device record. The tech remediates from the alert — RMM session, service restart, patch check — without switching tools. Alert resolution and ticket resolution update together, so SLA reporting becomes one query instead of a spreadsheet archaeology project.

The before/after is concrete. Old way: a disk alert emails a distribution list Friday evening, is discovered Monday by users, takes 60+ hours to resolve, and costs you one burned-out tech. AlertMonitor way: a contextual disk alert pages on-call at 11:40 p.m. with trend data, the tech acknowledges from their phone, connects to the endpoint, clears the runaway log directory or expands the volume, and the ticket auto-closes. Fifteen minutes, one page, and the outage that would have hit 40 users Monday morning never happens.

Practical Steps You Can Take This Week

1. Measure your actual noise ratio

Before you change anything, quantify it. Export the last seven days of alerts from your current tool and count duplicates:

# Audit alert noise: group last week's alerts by device and type
$alerts = Import-Csv .\last-7-days-alerts.csv
$alerts | Group-Object Device, AlertType |
    Sort-Object Count -Descending |
    Select-Object -First 15 Count, Name |
    Format-Table -AutoSize

If your top entry is a 300-count for one device and one condition, you have found your first deduplication and baseline candidate.

2. Replace blind thresholds with trend-aware checks

The alerts that actually wake you should carry the data a human needs to act. This is the kind of sweep worth running right now — in AlertMonitor it becomes a baseline-aware monitor automatically, but for a one-time audit across servers today:

# Find low disk space across servers, with trend-ready numbers
$servers = Get-Content .\servers.txt
Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter "DriveType=3" |
    Select-Object @{n='Server';e={$_.PSComputerName}},
                  @{n='Drive';e={$_.DeviceID}},
                  @{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
                  @{n='FreePct';e={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}} |
    Where-Object { $_.FreePct -lt 15 } |
    Export-Csv .\low-disk-report.csv -NoTypeInformation

For Linux members of the fleet, the same sweep:

df -h --output=source,pcent | awk '$5+0 > 85 {print $1, $5}'

3. Verify the services that actually break the business

Service-down alerts should be rare and always real. Sweep your critical services and see what is silently stopped right now:

# Check critical services across servers and report anything not running
$critical = 'wuauserv','Spooler','Dnscache','W32Time','MSSQLSERVER'
$servers = Get-Content .\servers.txt
foreach ($srv in $servers) {
    foreach ($svc in $critical) {
        $s = Get-Service -Name $svc -ComputerName $srv -ErrorAction SilentlyContinue
        if ($s -and $s.Status -ne 'Running') {
            [PSCustomObject]@{ Server = $srv; Service = $svc; Status = $s.Status }
        }
    }
}

Anything this script finds is an alert your current tool should have caught — and proof that its static thresholds do not match reality.

4. Write escalation policies that match how your team actually works

Severity- and clock-aware routing is the difference between one owned page and a distribution list where everyone assumes someone else is awake. In AlertMonitor, a policy looks like this:

escalation_policy: after_hours_critical
scope:
  severity: critical
  hours: outside_business_hours
steps:
  - notify: oncall_primary
    wait: 5m
  - notify: oncall_secondary
    wait: 10m
  - notify: it_manager
    channel: sms

Every page gets an owner and a deadline. Unacknowledged alerts escalate — they do not rot in an inbox.

5. Register maintenance windows around your patch schedule

If you run Patch Tuesday reboots between 10 p.m. and 2 a.m., suppress that window explicitly — not by muting the whole monitoring stack, but by scoping suppression to the devices and the window in question. In AlertMonitor, patch schedules and maintenance windows are linked: a reboot inside the window is silent, and a server that fails to come back after the window still pages you.

The Takeaway: Use AI to Make On-Call Human Again

The Pew survey is right that the workforce is anxious. But for the people keeping servers up and users working, the story is not AI replacing the technician. It is AI in the right place removing the noise that was making the job unbearable. A platform that deduplicates the storm, routes the real signal to the right person with full context, suppresses the planned noise, and closes the loop into the helpdesk does not make your on-call tech redundant. It makes them the reason clients renew — because their pager is quiet, their response is fast, and they are still on the team in two years.

Fewer overnight pages. Faster response. Teams that are not burned out by their own monitoring tools. That is what alert management should deliver — and it is what AlertMonitor was built to do.

Related Resources

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