£350M to Keep Applications Running: What the Atos–Met Police Deal Teaches Every IT Team About Remote Management

This week The Register reported that Atos has landed a six-year, £350 million contract with the Metropolitan Police to manage and secure the force's applications — with options to bolt on cloud and digital workplace services later.

Strip away the procurement language and the deal is about one thing: a very large organisation decided that keeping its applications up — and fixing them quickly when they fall over — is worth roughly £58M a year. Not new apps. Not a migration. Management, security, and availability of what already exists.

Here's the uncomfortable truth for everyone who isn't the Met Police: your team already owns most of the technical capability in that contract. Service monitoring, remote sessions, script execution, patch enforcement — it's all on your shelf. What you don't have is a £350M integrator gluing it together. Instead you have four or five disconnected consoles, a shared inbox, and a technician who found out the finance portal was down because the CFO called.

The Problem: Your Monitoring Says the Server Is Fine. Your Users Disagree.

Walk through the scenario every sysadmin has lived:

Monday, 09:12. The customer-facing portal starts throwing HTTP 503s. The IIS application pool on APP01 has entered a crash loop after last night's vendor update. Your monitoring stack — Zabbix, PRTG, Nagios, pick your poison — shows green. Host is up. Ping is 4ms. Port 443 is open. As far as the dashboard is concerned, everything is fine, because the dashboard watches servers, not applications.

Detection doesn't happen until the first user call hits the helpdesk at 09:20. Now the clock really starts:

• The service desk logs a ticket — 'portal down, can you check?'
• The technician switches to the RMM console (ConnectWise Automate, NinjaOne, Datto RMM — the one tool that can actually fix it) to find... nothing. The RMM doesn't know there's a problem, because detection lives in a different product.
• RDP into APP01, open Event Viewer, read 40 minutes of log entries, find the app pool crash loop, recycle the pool.
• Verify in a browser. Then — if there's time — manually write up what happened in the helpdesk and hunt through monitoring to correlate when the alerts (if any) fired.

Total elapsed time from first failure to verified fix: 35–45 minutes on a good day. During which the helpdesk collected 25–30 tickets for one root cause, none of them linked to each other or to the actual event. Your SLA report at the end of the month will count those as 30 separate breaches, and the bridge call on Friday will be about "why do we keep having portal outages" instead of "why did monitoring miss an app-level failure entirely."

Why the gaps exist

Because the stack was assembled, not designed. Each product was purchased in a different year, for a different problem, by a different manager:

• Monitoring (Zabbix, PRTG, SolarWinds) knows the host is up but has no ability to act beyond sending an email or a push notification.
• RMM (ConnectWise Automate, NinjaOne, Datto RMM) can execute scripts and open remote sessions, but it depends on its own limited monitors — and it has no idea what the monitoring platform or the helpdesk is doing.
• Helpdesk (ServiceNow, Freshservice, HaloPSA) records the human fallout but can't see machine state.
• Patching is a fourth system with its own console, its own compliance report, and its own reboot schedule nobody trusts.

Integration between them, where it exists, is webhook glue and CSV exports. The "device" in the RMM, the "node" in monitoring, and the "configuration item" in the helpdesk are three records that a human being reconciles by hand. That reconciliation is the actual job nobody put in the job description.

What it costs

• Detection gap: host-only monitoring misses application-level failures for 10–20 minutes on average — sometimes until a human notices.
• MTTR inflation: every tool switch adds context reload time. Five tools, twelve tabs, one confused technician.
• SLA fiction: duplicated tickets and unlinked events mean your availability and response reports are assembled from three systems that disagree with each other.
• Burnout: 2am pages for services a three-line script could have restarted. Every experienced tech has a mental list of alerts they've learned to ignore — that list is a resume risk for your entire monitoring investment.

For MSPs, multiply by client count. Supporting one client's print server means a monitoring tab, an RMM tab, a remote access tab, a PSA tab, and a documentation wiki — per client, per incident, all day.

How AlertMonitor Closes the Gap

The Atos contract exists because large organisations will pay enormous sums to have one accountable party own availability end to end. AlertMonitor gives internal IT teams and MSPs the same architectural principle — one platform, one timeline — without the seven-figure price tag.

One agent, one console, one timeline. Monitoring, RMM, helpdesk, and patch management share the same platform and the same device record. When the portal alert fires, the technician sees the alert, the device, its recent patch state, and its open tickets on a single screen.

Remote sessions without tab-switching. From the alert, one click opens a remote session to the endpoint. No separate remote access tool, no VPN hop, no credential hunting. The session is logged against the alert and the device automatically.

Scripts that run anywhere — and remember they ran. Push a script to one device or an entire device group (all IIS servers, all client DCs, all POS terminals). Script results feed back into the monitoring data, so an automated remediation at 03:00 and a manual fix by a technician at 09:30 appear in the same timeline. Your post-incident review stops being archaeology.

Automated remediation with real guardrails. Attach a stored script to a monitor condition: if the application pool is stopped on two consecutive checks, run the recycle script; if it's still failing after remediation, escalate to a technician with the remote session one click away. The service that used to page someone at 2am now fixes itself and leaves a note.

Helpdesk that sees machine state. The alert auto-links to the ticket, the remediation is attached, and the resolution timestamp comes from the platform — not from someone typing it in later. SLA reporting finally reflects what actually happened.

The same incident, in AlertMonitor

09:12 — application-level monitor detects the 503s. Alert fires. 09:12 — alert auto-creates a ticket and links it to APP01. 09:13 — automated remediation script recycles the app pool. Still failing. 09:14 — escalation to on-call tech, who opens a remote session directly from the alert, checks Event Viewer, rolls back the vendor update. 09:21 — portal verified up. Ticket updated automatically. The timeline shows every step: alert, script run, session, action, resolution.

Nine minutes. One console. Zero duplicate tickets.

Practical Steps You Can Take This Week

1. Monitor the application, not just the host. Add service and process checks for every business-critical application, plus an HTTP check that validates actual page content — not just a 200 response. In AlertMonitor these are standard checks on the same device record as everything else.

2. Turn your five most frequent manual fixes into stored scripts. Start with these:

Service watchdog — verify and restart a critical Windows service:

# Verify a critical service and restart it if stopped - safe to attach to a monitor
$serviceName = 'MyAppService'
$service = Get-Service -Name $serviceName -ErrorAction SilentlyContinue
if ($null -eq $service) {
    Write-Output ('Service {0} not found on this host' -f $serviceName)
}
elseif ($service.Status -ne 'Running') {
    Start-Service -Name $serviceName
    Write-Output ('Service {0} was {1} - started at {2}' -f $serviceName, $service.Status, (Get-Date))
}
else {
    Write-Output ('Service {0} is running normally' -f $serviceName)
}

IIS application pool health check with self-recovery:

# Check an IIS app pool and restart it if it is not running
Import-Module WebAdministration
$poolName = 'CustomerPortal'
$state = (Get-WebAppPoolState -Name $poolName).Value
if ($state -ne 'Started') {
    Start-WebAppPool -Name $poolName
    Write-Output ('App pool {0} was {1} - restarted at {2}' -f $poolName, $state, (Get-Date))
}
else {
    Write-Output ('App pool {0} is running normally' -f $poolName)
}

The Linux equivalent for your mixed estate:

# Restart nginx only if it has actually died
if ! systemctl is-active --quiet nginx; then
    systemctl restart nginx
    echo "nginx was down - restarted at $(date)"
fi

3. Get ahead of the 2am disk page. Run this across a device group weekly — or better, let scheduled scripts handle it and alert only on trend:

# Free disk space across a group of servers, sorted worst-first
$servers = 'APP01','APP02','SQL01','FILE01'
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='TotalGB';e={[math]::Round($_.Size/1GB,1)}} |
    Sort-Object FreeGB | Format-Table -AutoSize

4. Know your patch posture before the auditor does. A quick compliance snapshot for a server — in AlertMonitor this is a built-in report, but if you're still consolidating tooling, start here:

# Show the five most recent hotfixes on a remote server as a quick patch-compliance sanity check
Invoke-Command -ComputerName 'APP01' -ScriptBlock {
    Get-HotFix | Sort-Object InstalledOn -Descending |
        Select-Object -First 5 HotFixID, Description, InstalledOn
}

5. Wire the loop together. In AlertMonitor: save the service-watchdog script, attach it to the service monitor for your application device group, set the condition to two consecutive failed checks, and let the platform handle remediation, escalation, and ticket updates automatically. The alert, the script result, the remote session, and the ticket resolution all land in one timeline — visible to whoever picks up the phone next.

The Takeaway

The Met Police is spending £350M to buy a single accountable party for application availability. You don't need their budget — you need their architecture: detection, remediation, access, and accountability in one system instead of five. When monitoring, RMM, helpdesk, and patching share one platform and one timeline, the gap between alert and resolution stops being measured in coffee breaks and starts being measured in minutes.

Related Resources

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