The Register recently reported that Amazon is telling its own developers to stop "tokenmaxxing" — flooding codebases with huge AI-generated diffs that look productive but don't actually move business goals. The internal message: focus on useful software and real outcomes, not volume.
Swap "codebase" for "RMM script library" and you have a precise description of what is happening inside a lot of IT departments and MSPs right now. Copilots and LLMs have made it trivial for any technician to generate a remediation script in thirty seconds. Push it to a device group, schedule it, done. Six months later you have 140 scripts with names like fix_disk_v2_FINAL.ps1, half of them undocumented, a third of them scheduled "just in case," and nobody — including whoever wrote them — entirely sure what they do.
Automation volume is up. Time between alert and resolution? Often unchanged. Sometimes worse. Meanwhile the on-call phone still rings at 2 a.m. for the same disk-full page the "successful" nightly cleanup script was supposed to prevent.
What "Tokenmaxxing" Looks Like Inside an IT Team
If any of these feel familiar, you are living it:
- A disk cleanup script that has "run successfully" every night for three months — on a file server that still pages the on-call tech about low disk space every three weeks.
- A service restart automation credited with resolving 60+ tickets this quarter. Sixty tickets. Same service. Nobody has asked why it keeps stopping.
- A patch compliance script pushed to 300 endpoints "to see where we stand." The results became a CSV, the CSV landed in someone's Downloads folder, and the next audit started from zero.
- A script library whose only documentation is the AI chat history of the technician who generated it — who left the company in March.
Each script was a genuine attempt to solve a real problem. But automation without a feedback loop is not automation. It is noise with a schedule.
The Problem in Depth: Siloed Tooling Breaks the Feedback Loop
The architecture punishes the loop
Most teams run some version of this stack: a monitoring tool that detects problems but cannot act on them (PRTG, Zabbix, SolarWinds), an RMM that can execute but does not watch outcomes (ConnectWise Automate, NinjaOne, Datto RMM), and a helpdesk that records what happened but is blind to both (Freshservice, HaloPSA, ConnectWise Manage if you are lucky enough to have them integrated).
In that architecture, a script's execution result dies in a script log. Whether the underlying alert actually stayed resolved — the only outcome that matters — lives somewhere else entirely, if anyone tracks it at all. So the loop never closes:
- Alert fires in the monitoring console.
- Technician (or a scheduled automation) runs a script from the RMM.
- Script exits 0. Looks done.
- Alert re-fires in 20 minutes, or three weeks — or never gets correlated at all.
- Repeat, forever, with the ticket count to prove it.
What it costs
- Recurring incidents get laundered into "resolved" tickets. Every spooler restart is a closed ticket. The pattern — one print server failing 14 times a month — stays invisible unless someone manually cross-references the helpdesk against script logs. Nobody has time for that, so the root cause gets fixed by a hardware refresh, two years late.
- MTTR reports lie. Closure is triggered by "script ran" rather than "problem stayed gone," so mean-time-to-resolve looks excellent while users keep re-ticketing the same issue. The IT manager cannot produce a defensible SLA report because the proof of resolution lives in three systems that do not talk to each other.
- On-call burnout compounds. The tech who got paged at 2 a.m. anyway stops trusting automation, starts doing everything manually, and burns out faster. Now your best people are your slowest path to resolution.
- MSPs feel it per client. Twelve clients, twelve script libraries, no unified view of which automations prevent incidents versus generate busywork. QBR preparation becomes an archaeology project.
These gaps exist because the tools were built as separate products: separate agents, separate data models, separate logs. Integration, where it exists, is an afterthought — an API sync that pushes tickets one direction and nothing back.
What Useful Automation Looks Like
Amazon's filter for its developers applies directly to IT automation: does this output accomplish a goal, or does it just produce output? Useful automation has four properties:
- It targets a recurring, measured problem — not something that "might be useful someday."
- Its result lands next to the alert it addressed, on the same timeline, so anyone can see whether the alert stayed resolved.
- It reports status in plain, machine-readable output — OK / RECOVERED / ESCALATE — not just an exit code.
- It escalates when it fails, so a failed remediation becomes a new alert instead of a silent gap.
That fourth property is where most teams lose. A script that fails silently is worse than no script, because it creates false confidence in your environment's coverage.
How AlertMonitor Closes the Loop
AlertMonitor's RMM lives inside the same platform as monitoring, helpdesk, patching, and network topology — and that single design decision is what makes closed-loop automation possible.
Concretely:
- No tab-switching between the monitoring console and the RMM. Technicians remotely view and manage endpoints, run scripts across device groups, push software, and open remote sessions from the same console where the alert fired.
- Script results feed back into the monitoring data. When an automated remediation runs, its output attaches to the same timeline as the alert. Manual technician actions land on the same timeline. Anyone reviewing the incident sees the alert, the action, the output, and the outcome in one record.
- Closure reflects reality. An alert closes because the condition cleared — not because a script exited cleanly. If the disk fills again in 48 hours, the timeline shows the previous remediation, its output, and the fact that it did not hold. Root cause analysis starts from evidence instead of memory.
- The helpdesk sees what actually happened. The ticket is not just "resolved — ran script." It includes the automation output, so the second-line tech or the client can see exactly what was done.
The old fragmented way: alert in PRTG → RDP or ConnectWise session → run the script → check output in Automate's log → update the ticket in Freshservice → manually close the alert in PRTG. Twenty-five to forty minutes of context-switching per incident, with the audit trail scattered across four systems.
The AlertMonitor way: alert fires → run the stored remediation against the device or device group → output appears on the alert timeline → condition clears, alert closes, ticket updates. For a stopped-service recovery, that is under two minutes end to end, with a complete record.
The time savings are real, but the bigger win is trust: automation you can audit is automation you can safely expand.
Practical Steps: Automate With Purpose Starting Today
1. Inventory what you already have. Before generating one more script, list every automation in your RMM: what it targets, when it last ran, and whether the condition it addresses has re-fired since. Anything with recurring re-fires is automation that is not working. Anything nobody can explain is a liability. Retire ruthlessly.
2. Make every script report status, not just exit. Here is a disk usage check across servers that outputs a per-drive verdict your platform can attach to the device timeline:
$servers = @('FS01','FS02','SQL01','DC01')
$thresholdPct = 85
$report = foreach ($server in $servers) {
Get-CimInstance -ComputerName $server -ClassName Win32_LogicalDisk -Filter 'DriveType=3' |
ForEach-Object {
$freePct = [math]::Round(($_.FreeSpace / $_.Size) * 100, 1)
[PSCustomObject]@{
Server = $server
Drive = $_.DeviceID
FreeGB = [math]::Round($_.FreeSpace / 1GB, 1)
FreePct = $freePct
Status = if ($freePct -lt $thresholdPct) { 'ALERT' } else { 'OK' }
}
}
}
$report | Format-Table -AutoSize
$report | Export-Csv -Path "C:\Reports\DiskUsage_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation
3. Give remediation scripts an explicit escalation output. A service recovery script should tell you — loudly — when it failed:
$services = @('W32Time','Spooler','wuauserv')
foreach ($name in $services) {
$svc = Get-Service -Name $name -ErrorAction SilentlyContinue
if ($null -eq $svc) {
Write-Output "[$name] NOT INSTALLED - skip"
continue
}
if ($svc.Status -ne 'Running') {
Write-Output "[$name] STOPPED - attempting start"
Start-Service -Name $name
Start-Sleep -Seconds 10
$svc.Refresh()
if ($svc.Status -eq 'Running') {
Write-Output "[$name] RECOVERED"
} else {
Write-Output "[$name] STILL DOWN - ESCALATE"
}
} else {
Write-Output "[$name] OK"
}
}
That ESCALATE line is the whole point. Run from AlertMonitor, the output lands on the alert timeline, so a failed recovery is visible immediately instead of being discovered at the next page.
4. Same discipline on the Linux side of the fleet:
#!/bin/bash
# Report disk usage on critical mount points
THRESHOLD=85
for mount in / /var /home; do
usage=$(df --output=pcent "$mount" | tail -1 | tr -dc '0-9')
if [ "$usage" -ge "$THRESHOLD" ]; then
echo "ALERT: $mount at ${usage}% usage"
else
echo "OK: $mount at ${usage}% usage"
fi
done
# Service check that self-reports its outcome
systemctl is-active --quiet nginx && echo "nginx OK" || {
systemctl restart nginx
sleep 5
systemctl is-active --quiet nginx && echo "nginx RECOVERED" || echo "nginx DOWN - ESCALATE"
}
5. Review automation quarterly against outcomes, not run counts. The question is not "did the script run?" It is "did the alert it addresses fire again within 30 days?" In AlertMonitor both the script execution and any subsequent re-fire sit on the same timeline, so this review takes minutes instead of becoming a cross-system spreadsheet project.
Focus on What Matters
That is really what Amazon is telling its developers, and what IT leaders should tell their teams: the goal is not maximum output, it is outcomes that move the business. For an IT team, that means fewer recurring alerts, less time between alert and resolution, SLA reports you can defend, and end users who stop re-ticketing the same problem.
You do not get there by generating more scripts. You get there by putting every script — AI-generated or hand-written — where its result gets measured against the alert it was meant to fix. That is the difference between tokenmaxxing your RMM and actually automating your operations.
Related Resources
AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.