The Register recently revisited one of the strangest episodes in browser history: the engineer who built Google's Pac-Man doodle — the first playable doodle, shipped in 2010 for the game's 30th birthday — explained how the little JavaScript arcade cabinet misbehaved in Firefox. Runaway sound loops, spiking resources, frozen tabs, and very confused users. A cheerful game meant to waste five minutes of office time turned into a support incident for anyone running Mozilla's browser.
Here is the part that should make every sysadmin wince. When the doodle went rogue, how did IT teams find out? Not from their monitoring consoles. They found out because a user walked over, or Slack lit up, or the ticket queue filled with variations of 'my browser is making a weird noise and now it will not respond.' The tools that were supposed to provide visibility were either silent on the actual cause or generating so much generic workstation noise — CPU spikes, nobody knows why — that nobody read them anymore.
That is the alert management problem in miniature, and it is happening in your environment every single night, at much larger scale. Ask yourself honestly: how many alerts did your team receive between 10 p.m. and 6 a.m. last night? How many required a human to do anything? If the answer to the second question is anywhere close to the first, you do not have a monitoring problem. You have a signal quality problem.
The Problem in Depth: Your Monitoring Tool Is a Waka-Waka Machine
What legacy tooling gets wrong
Most IT shops run infrastructure monitoring from one vendor (PRTG, Zabbix, LibreNMS, SolarWinds), RMM from another (ConnectWise, NinjaOne, Atera), and a helpdesk from a third (ServiceNow, Freshservice, Jira Service Management). Each tool alerts in isolation, and each one behaves like it is the star of the show.
The failure modes are painfully predictable:
- Static thresholds with zero context. 'CPU greater than 90% = alert.' A workstation running a browser that has gone waka-waka triggers it. So does a legitimate backup job, a Teams update, a user rendering video. The alert says the same thing in every case: a number crossed a line. It never says what changed, whether that is normal for the device, or whether anyone should care.
- No deduplication or flapping suppression. With a five-minute poll interval, one misbehaving endpoint generates 12 identical alerts an hour. Multiply by 40 endpoints showing the same symptom and your queue holds 480 entries describing exactly one problem.
- No link between alerts and tickets. Fifteen users file 'Firefox is frozen' tickets while monitoring fires 40 CPU alerts. Nothing correlates them. Two technicians work the same incident from opposite ends and neither has the full picture.
- All-or-nothing escalation. Either everything pages on-call or nothing does. There is no concept of 'this is a workstation, business hours only' versus 'this is a production SQL server, wake someone up.'
Why the gaps exist
These are not dumb tools — they are old architectures. Standalone monitors predate the idea of a shared data model, so they poll devices and emit events without knowing what a client is, what a healthy baseline looks like, or what the helpdesk is hearing. RMM platforms grew out of patch and script engines, so monitoring is bolted on. Helpdesks grew out of ticket databases; they see what users type, not what devices do. Integration, where it exists, is a webhook or a CSV export — not a shared incident timeline.
There is also an economic problem: per-device licensing on some platforms makes teams reluctant to monitor deeply across every endpoint, so the blind spots land exactly where users actually work — their workstations and, yes, their browsers.
What it actually costs
- Mean time to acknowledge balloons. When technicians receive 600 alerts a day and know most are junk, they stop watching the queue in real time. Real incidents sit for 30-45 minutes before a human looks. If your SLA promises a 15-minute response, you are already losing.
- Real fires hide in the smoke. The one alert that mattered — the file server at 96% disk, the domain controller with a degraded RAID array — scrolls off screen somewhere between page 4 and page 40 of the morning digest.
- Burnout and turnover. Nobody stays long in a job where the phone goes off at 2 a.m. and the answer, four times out of five, is 'that is just the monitor being the monitor.'
- The Pac-Man scenario, at scale. Friday, 2:40 p.m. A browser process goes runaway across one floor — 40 workstations pegged above 95% CPU, fans screaming, users filing tickets. Monitoring fires a fresh alert per endpoint per poll cycle. Nobody correlates them. The NOC assumes a datacenter issue; the helpdesk assumes user error; the actual cause — a single misbehaving web process — sits untouched for an hour.
How AlertMonitor Turns Noise Into Signal
AlertMonitor was designed around a specific insight: alert fatigue is not a volume problem, it is a signal quality problem. You do not fix a noisy monitor by muting it or bolting on more thresholds — you fix it by making every alert worth reading.
Every alert carries full context. An AlertMonitor alert for CPU saturation does not say 'WS-FIN-1042 CPU 95%.' It says: device WS-FIN-1042, client Meridian Finance, process firefox.exe at 96% for 11 minutes, healthy baseline for this workstation at this hour is 14%, deviation started at 2:41 p.m. A technician triages that in five seconds without opening a second tool.
Smart deduplication collapses cascades. Those 40 endpoints with the identical signature become one correlated incident with a list of affected devices — not 40 independent alerts. One notification, one owner, one timeline, and the blast radius visible at a glance.
Escalation that matches reality. Multi-level on-call routing means workstation noise follows business-hours policy and lands in the tier-1 queue as a ticket, while a production server failure after hours pages the NOC primary immediately and escalates to the IT manager if unacknowledged in 10 minutes. You define what deserves a 2 a.m. page; the platform enforces it.
Maintenance windows stop self-inflicted noise. Patch Tuesday deploys trigger service restarts and CPU spikes on every endpoint you touch. With maintenance window suppression, AlertMonitor stays quiet during the window and hands you a summary afterward instead of paging you about your own changes.
One platform instead of five tabs. Because monitoring, RMM, helpdesk, and patching share one data model, the helpdesk tickets saying 'my browser is frozen' attach to the same incident as the monitoring alerts. The technician sees users plus devices plus telemetry in one view, can remote into any affected machine from the alert card, and can push a remediation script to all 40 devices in a single action.
The before-and-after is not subtle. Teams that move off fragmented tooling typically see mean time to acknowledge drop from 30-40 minutes to under two, and overnight pages fall by 60-80% — not because monitoring got quieter, but because every remaining page means something.
Practical Steps You Can Take Today
1. Audit your alert noise. Pull the last 30 days of alerts from whatever tool you run today. Count total alerts, how many a human acknowledged, and how many auto-expired or were closed without action. If more than half were never actioned, you have your answer: your team has already learned to ignore your monitoring.
2. Alert on deviation, not absolutes. Replace 'CPU greater than 90%' with 'CPU above 3x its hourly baseline for 10+ minutes.' Baseline-aware alerting kills most of the noise on day one.
3. Write the escalation ladder down. Define, in writing, what may page a human between 10 p.m. and 6 a.m. Hint: customer-impacting production failures only. Workstation weirdness waits for morning. In AlertMonitor, that ladder is configuration, not tribal knowledge:
policy: ws-cpu-saturation
trigger:
metric: cpu.utilization
condition: '> 90'
duration: 10m
scope: device_type = workstation
deduplication:
key: '{{client}}:{{device}}:cpu-saturation'
window: 30m
correlate_by: process-signature
schedule:
business_hours: tier1-helpdesk
after_hours: silent-to-ticket
escalation:
- acknowledge_within: 15m
then: notify tier1-lead
suppression:
maintenance_windows:
- patch-tuesday-deploy
The same metric on a production SQL server gets the opposite policy: page immediately, escalate on silence.
**4. Put maintenance windows around every change.** If your team deploys patches, restarts services, or reboots servers, those events should never page anyone. Suppress during the window; review the summary after.
**5. Keep a runaway-process triage script handy.** When the next Pac-Man moment hits — a browser, an updater, or a scanner service gone rogue — this is the first thing to run against the noisy endpoint:
```powershell
# Top CPU consumers on a remote workstation: the 'why is this machine screaming' check
Invoke-Command -ComputerName WS-FIN-1042 -ScriptBlock {
Get-Process |
Sort-Object CPU -Descending |
Select-Object -First 10 Name, Id, CPU,
@{n = 'MemMB'; e = { [math]::Round($_.WorkingSet64 / 1MB) }},
@{n = 'Responding'; e = { $_.Responding }}
}
And when one user's complaint turns out to be a floor-wide pattern, sweep the fleet and capture the blast radius in one pass:
# Find every endpoint with a runaway browser process before the tickets do
$workstations = Get-Content C:\IT\workstations.txt
Invoke-Command -ComputerName $workstations -ScriptBlock {
Get-Process |
Where-Object { $_.CPU -gt 600 -and $_.Name -match 'firefox|chrome|msedge' } |
Select-Object Name, Id, CPU
} -ErrorAction SilentlyContinue |
Select-Object PSComputerName, Name, Id, CPU |
Sort-Object CPU -Descending |
Export-Csv C:\IT\reports\browser-cpu-hogs.csv -NoTypeInformation
Inside AlertMonitor, that second script is not something you run manually at all — it is a remediation action attached to the deduplicated incident, pushed to all affected devices in one click, with results captured on the incident timeline for the postmortem and the client report.
The Takeaway
The Pac-Man doodle is a charming story about a fun experiment that got out of hand in one browser. It resonates with IT teams because it is a perfect miniature of every alert storm you have ever lived through: software misbehaving in a way nobody predicted, users noticing before the tools did, and a support team left to reconstruct the incident from fragments scattered across systems that do not talk to each other.
Noise is delightful in an arcade game and corrosive in a NOC. Your on-call rotation should hear waka-waka when there is an actual ghost to chase — and silence when there is not.
Related Resources
AlertMonitor Alert Management & On-Call Operations AlertMonitor Platform Overview Book a Demo Alert Management & On-Call Operations Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.