From Safety Driver to Self-Healing: What Wayve's Paid Robotaxi Launch in London Teaches IT Teams About Automated Remediation

The News, and Why It Should Matter to You

Wayve and Uber just did something Waymo hadn't: they started charging real passengers for self-driving rides in London. Fifteen Mustangs are working city streets right now — every single one with a safety driver aboard, logging everything the system does. The follow-up fleet of Nissan LEAFs is designed to dispense with the safety driver entirely.

That is not a smaller ambition. It is a smarter sequence. Wayve did not leap straight to driverless. They put supervised autonomy on the road first, let the system earn trust with a human as the backstop, and defined a clear graduation path to full autonomy.

If you run IT operations — an internal team, or an MSP NOC covering a dozen clients — you should recognize that playbook, because it is exactly how automated remediation should roll out in your environment. And it is exactly how most teams never do it.

The Real Problem: Your Alert Cannot Lift a Finger

Here is the 2 a.m. version most sysadmins know by heart:

1. 02:14 — Your monitoring tool (Zabbix, PRTG, SolarWinds, whatever you inherited) pages: SQL01 — C: drive at 92% and climbing.
2. 02:16 — The on-call tech wakes up, opens the monitoring console, confirms the alert is real.
3. 02:20 — They open a second tool — TeamViewer, AnyDesk, ScreenConnect — to remote into the box.
4. 02:25 — They open a third tool to check whether a patch or a log bloat caused it. Maybe WSUS, maybe a separate RMM, if one exists.
5. 02:40 — They run a cleanup manually in a PowerShell window. The output vanishes into their local terminal history.
6. 02:45 — Too tired to write a ticket, nobody writes one. The alert auto-closes in the monitoring tool.
7. 09:00 — The IT manager asks why SQL01 nearly filled its disk. The helpdesk shows no incident. The monitoring tool shows an alert with no resolution notes. The SLA report says the incident never happened — or clocks MTTR at six hours because nobody closed the loop.

Nothing in that workflow detected the problem slowly. The fix itself took four minutes. Everything around the fix — tab-switching, context-gathering, documentation — consumed the other forty.

Why the Tools Are Like This

Because they were built by different companies, in different eras, on different data models:

• Monitoring platforms (Nagios, Zabbix, PRTG, SolarWinds) grew out of the SNMP-era network ops world. They are built to watch, not to act. The best most of them offer is a webhook: create a ticket in the helpdesk and forget about it.
• RMM platforms (ConnectWise Automate, NinjaOne, Syncro) grew out of endpoint management. They run scripts beautifully — but infrastructure monitoring is often an afterthought, and their alerting engine lives apart from whatever your ops team already watches.
• Helpdesks (ConnectWise Manage, Freshservice, Jira Service Management) grew out of ITIL. They track work, but they only know what a human typed into them. Script results, remote session logs, and patch state changes never flow back.

So you get integrations that are one-way streets. The alert creates a ticket, but the script result never updates the ticket, the remote session never gets logged against it, and patch status never reconciles with the alert. Every tool holds a piece of the truth; no tool holds the whole story.

What It Actually Costs

• MTTR inflation. In scriptable incidents — service restarts, stuck print queues, disk cleanups, cache flushes — the majority of resolution time is context-gathering and tool-switching, not the actual fix.
• Ticket volume that should not exist. Across the environments we see, service restarts, spooler clears, and drive-full complaints routinely account for a quarter to a third of helpdesk volume. Nearly all of it is scriptable.
• Alert fatigue and burnout. Every 2 a.m. page a script could have handled is a withdrawal from your on-call tech's trust account. Eventually they stop answering pages at all — and the next one is the real outage.
• MSP math. Twelve clients means twelve credential sets, twelve portal combinations, and a patch-compliance report assembled by exporting CSVs and merging them in Excel the night before a QBR. The report is stale before the meeting starts.

The Wayve Model, Applied to Your RMM

Wayve's approach works because autonomy is graduated. Map the same three stages onto remediation:

Most teams are stuck shuttling between Stage 1 and premature Stage 3 — a cron job someone wrote in 2022 that nobody dares touch because nobody knows what it does. The missing ingredient is not intelligence; it is observability of the automation itself. A safety driver works because everything the system does is visible, logged, and reviewable. Your remediation scripts need the same property.

That requires the automation to live in the same place as the monitoring data, the remote access, and the tickets. That is precisely the problem AlertMonitor was built to eliminate.

How AlertMonitor Closes the Loop

AlertMonitor is one platform, one agent, one console: infrastructure monitoring, RMM, helpdesk, patch management, and network topology on a single data model. Concretely, here is how the 2 a.m. story changes:

• Click the alert, not a tab. Every alert links directly to the device view, and from there one click opens a remote session on the endpoint — no VPN, no separate remote-access product, no credential juggling. For an MSP, it works identically across every client site from the same NOC dashboard.
• Scripts run where the alerts live. Build a script library in PowerShell or Bash, target device groups — all SQL servers, Site A workstations, a client's full fleet — and run on demand, on schedule, or triggered by an alert.
• Every action lands in one timeline. Script results feed back into the monitoring data. The alert, the automated remediation, its output, the technician's remote session, the patch state change, and the linked helpdesk ticket all appear on the same incident timeline. When the manager asks what happened on SQL01, the answer is one screen, not three tools and a hypothesis.
• Supervised remediation, then self-healing. Start with alerts triggering scripts in supervised mode — the script runs, output is captured, a tech reviews. Once a script's success rate earns trust, flip it to fully automated: it heals the issue, opens its own ticket for the record, and the platform verifies recovery against the original alert condition. That is the safety driver leaving the seat — deliberately, with data behind the decision.
• Patching in the same view. Patch compliance is visible per device and per group, and non-compliant machines are remediated from the same console — no CSV export, no Excel merge, no stale QBR deck.

The outcome is boring and wonderful: scriptable incidents drop from 40-plus minutes of alert-to-resolution to under five, and the on-call phone stays quiet unless a human genuinely needs to be in the loop.

Do This Today: Build Your First-Responder Script Library

You do not need a migration project. Pick your five most common incident types, write one script for each, and put them where your alerts can reach them. Here are five to steal.

1. Disk space sweep across your server group

# Disk sweep - deploy via AlertMonitor's script engine against your server device group
$servers = @('SQL01','FS01','DC01','APP02','RDS03')
Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter 'DriveType=3' -ErrorAction SilentlyContinue |
    Select-Object PSComputerName, DeviceID,
        @{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
        @{n='TotalGB';e={[math]::Round($_.Size/1GB,1)}},
        @{n='FreePct';e={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}} |
    Where-Object { $_.FreePct -lt 15 } |
    Sort-Object FreePct |
    Format-Table PSComputerName, DeviceID, FreeGB, TotalGB, FreePct -AutoSize

Schedule it daily. The output lands in your monitoring timeline, so the trend is visible long before anything pages anyone.

2. Critical service watchdog with restart and audit trail

# Watchdog: verify critical services, restart any that stopped, report what it did
$critical = @('MSSQLSERVER','IISADMIN','W32Time','Spooler')
$report = foreach ($name in $critical) {
    $svc = Get-Service -Name $name -ErrorAction SilentlyContinue
    if ($svc -and $svc.Status -ne 'Running') {
        try {
            Start-Service -Name $name -ErrorAction Stop
            [pscustomobject]@{ Service=$name; Was=$svc.Status; Now='Running'; Action='Restarted' }
        } catch {
            [pscustomobject]@{ Service=$name; Was=$svc.Status; Now=(Get-Service $name).Status; Action="FAILED: $($_.Exception.Message)" }
        }
    }
}
if ($report) { $report | Format-Table -AutoSize } else { Write-Output 'All critical services running.' }

Attach it to a service-stopped alert in supervised mode first. Review a few weeks of runs, confirm the restart success rate, then graduate it to silent self-healing. The report posts to the incident timeline and opens a ticket automatically — an audit trail a safety driver would envy.

3. The print spooler clear (the eternal ticket)

# Stuck print queue - clears spooler jam and confirms recovery
Stop-Service -Name Spooler -Force
Remove-Item -Path "$env:SystemRoot\System32\spool\PRINTERS\*" -Force -ErrorAction SilentlyContinue
Start-Service -Name Spooler
Get-Service -Name Spooler | Select-Object Name, Status

This one ticket type consumes an absurd share of helpdesk hours in most organizations. Automate it once and reclaim them permanently.

4. Patch compliance check for Windows endpoints

# Patch posture: pending updates and reboot state on this endpoint
$session  = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$result   = $searcher.Search('IsInstalled=0 and IsHidden=0')
Write-Output ('Pending updates: {0}' -f $result.Updates.Count)
$result.Updates | ForEach-Object { Write-Output (' - {0}' -f $_.Title) }

$rebootPending = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
Write-Output ('Reboot pending: {0}' -f $rebootPending)

Run it across your workstation groups weekly and the compliance number in your next report is generated, not hand-assembled.

5. Linux servers deserve the same treatment

#!/bin/bash
# Linux watchdog: restart nginx if down, report root disk usage
if ! systemctl is-active --quiet nginx; then
    systemctl restart nginx
    logger -t alertmonitor 'nginx was inactive - restarted'
    echo 'nginx: was down, restarted'
else
    echo 'nginx: running'
fi
df -h / | awk 'NR==2 {print "root filesystem: " $5 " used"}'

The Rollout Cadence

1. Week 1 — Group devices by role and site in AlertMonitor. Load the scripts above into the library.
2. Weeks 2–4 — Run everything in supervised mode: scripts fire on alerts, techs review every output in the timeline.
3. Month 2 — Promote proven scripts to full self-healing. Anything that still needs a human routes into the helpdesk with monitoring context already attached.
4. Monthly — Review script success rates. Promote, tune, or retire. That is your version of reading the safety-driver logs before removing the driver.

Wayve did not remove the safety driver on day one, and they did not keep it forever. They made the call with data. Your remediation automation deserves the same discipline — and a platform where the monitoring, the scripts, the remote sessions, and the tickets all tell one story.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources