Asahi Linux just crossed a major threshold: support for Apple's M3 silicon. Most of the hardware works. Graphics acceleration, sleep behavior, and external displays still need attention — and the Asahi team says so right up front.
For kernel developers, that's a milestone worth celebrating. For anyone who runs endpoints for a living, it's the most familiar sentence in IT: "Most of it works. A few things don't. We'll get to those."
That gap — the 10% that doesn't work — is exactly where helpdesk queues, 2 a.m. pages, and burned-out technicians come from. And it's exactly the gap self-healing and proactive automation are built to close.
Every Fleet Has Its Own "M3 Problem"
You don't need to run Linux on Apple Silicon to live this. Every environment has platforms and updates that are 90% there:
- The Windows 11 24H2 machines where a specific print driver wedges the Spooler after every reboot, and users "fix" it by rebooting twice.
- The conference room Mac that never actually sleeps after the last macOS update, so it shows up offline in the RMM every Monday morning.
- The dock firmware update that quietly breaks external display wake — the laptop is fine, the user's second monitor is black, and nobody notices until the 9 a.m. stand-up.
- The Linux box — maybe an M3 running Asahi, maybe a Proxmox host — whose systemd journal has been silently eating disk for three weeks.
Here's what all of these have in common: the device passes every traditional health check. It pings. The agent reports in. CPU and memory look normal. Yet the user experience is degraded, and the first "monitoring system" to detect the problem is Susan from accounting opening a ticket.
If your tooling only notices problems when humans do, you don't have monitoring. You have an expensive uptime dashboard.
Why Existing Tools Miss It
Standalone monitoring — PRTG, Zabbix, SolarWinds — is built around device-centric metrics: ping, SNMP, CPU, disk. It answers "is it up?" It has no concept of "sleep is broken," "the GPU fell back to software rendering," or "the external display didn't come back after resume." Those states simply don't exist in its data model.
Your RMM — NinjaOne, ConnectWise RMM, Datto — absolutely can fix these things. The scripting engines are excellent. But in most shops, remediation lives in a technician's head. A tech notices the third "monitor won't wake" ticket this week, recognizes the pattern, writes a PowerShell script, and pushes it to the one device that ticketed. Next week the same failure appears on a machine nobody scripted. The knowledge never became automation.
Your helpdesk — Freshservice, HaloPSA, ConnectWise Manage — knows about every problem your monitoring never sees, and nothing about the ones it does. There's no correlation between the ticket stream and the telemetry. So every recurring soft failure triggers the same manual archaeology: remote in, poke around, reboot, close the ticket, wait for the re-open.
And when teams do automate at scale, they usually skip the safety step. Someone writes a log-cleanup script and pushes it to 400 endpoints in one shot. A wildcard is wrong, or the script conflicts with an EDR, and now you have a self-inflicted fleet-wide incident at 4 p.m. on a Friday. Untested automation is how a quick fix becomes an outage.
These gaps exist because the tools were built in different eras, on different data models, with no shared device timeline. Monitoring has metrics. The helpdesk has workflow. The RMM has execution. Nobody owns the full loop: detect → verify → fix → confirm → document.
What It Actually Costs
Run the numbers on one recurring soft failure across a 300-device fleet:
- MTTR: a degraded-but-"up" issue averages 45–90 minutes across ticket triage, remote session, diagnosis, and follow-up. The same issue with an attached runbook resolves in minutes, unattended.
- Ticket volume: one broken sleep state across a fleet easily generates 20–40 tickets a month. Every one of them is the same ticket. All of them are avoidable.
- After-hours pages: monitoring pages you for the symptoms it understands (disk full) at 2 a.m., but not for the trends heading toward failure. That's how alert fatigue starts — and once techs start ignoring alerts, they ignore the real ones too.
- SLA reporting: when monitoring data and ticket data live in separate systems, you know when the ticket closed but not when the issue started. Your SLA report is fiction, and your IT manager knows it.
The MSP version is worse. Picture 40 clients, 3,500 endpoints, and one display-wake bug after a dock firmware rollout. Two weeks and 60 near-identical tickets before someone isolates a one-line power configuration. That's dozens of burned tech hours, three annoyed client contacts, and a CSAT dip — over a problem a canaried runbook would have caught on device six, not device four hundred.
How AlertMonitor Closes the Loop
AlertMonitor exists precisely because "detect" and "resolve" should not be separate products.
Runbooks attached to alert conditions. In AlertMonitor, an alert condition — a stopped service, disk above 90%, an event-log pattern, a device that failed to check in after its scheduled resume window — can trigger a runbook automatically. The runbook restarts the service, clears temp space, rotates logs, or calls a webhook. No human gets paged unless remediation fails or the condition starts flapping. The loop is: detect, fix, verify, log — and only then escalate.
Canary deployment monitoring. Every script, agent update, and patch rollout goes to a pilot group first — five to ten representative devices across your OS builds and hardware generations. AlertMonitor tracks success rates, resource impact, and error events on the pilot ring, and holds the fleet-wide push if the canaries regress. This is the exact discipline that separates "we automated and it went badly" from "we automated safely."
One timeline per device. The alert, the runbook that fired, the ticket it opened (or didn't), the patch state, and the config change all live on a single device record. When ticket #4 about a black monitor comes in, the tech sees tickets #1–3, the dock firmware update, and the remediation history in one view. Root cause on the first look, not the sixtieth.
Helpdesk that's integrated, not bolted on. A self-healed alert writes a closed-loop record automatically. An alert that needs a human opens a ticket pre-populated with telemetry — the user describes the symptom once, and the tech starts with data instead of a screen-share.
Patching inside the same loop. Patch compliance is a monitored condition, not a monthly spreadsheet export. A failed patch triggers an alert, the alert can trigger a retry or rollback runbook, and the rollout itself runs canary-first across the fleet.
Old workflow: user tickets → triage → remote session → manual script → close ticket → repeat next week. New workflow: condition fires → runbook remediates in minutes → verification passes → timeline logged → humans only involved if the machine couldn't heal itself. That's the difference between a 60-ticket month and a zero-ticket month for the same underlying fault.
Practical Steps: Build Your First Self-Healing Loops This Week
Step 1: Mine your ticket history. Pull the last 90 days of tickets and group by symptom. You'll find 8–10 recurring "soft failures" — the sleep issues, the spooler resets, the disk hogs. That list is your runbook backlog, priority-ordered by ticket volume.
Step 2: Write the remediation scripts. Two examples that map directly to the failure patterns above.
Disk space — clean up before the 2 a.m. page instead of after:
$threshold = 90
$drive = Get-PSDrive -Name C
$usedPct = [math]::Round(($drive.Used / ($drive.Used + $drive.Free)) * 100, 1)
if ($usedPct -ge $threshold) {
Write-Output "C: at $usedPct percent - running automated cleanup"
Remove-Item "$env:TEMP\*" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "C:\Windows\Temp\*" -Recurse -Force -ErrorAction SilentlyContinue
Clear-RecycleBin -Force -ErrorAction SilentlyContinue
Dism.exe /Online /Cleanup-Image /StartComponentCleanup | Out-Null
Write-Output "Done. Free space now: $([math]::Round((Get-PSDrive C).Free / 1GB, 1)) GB"
}
Service watchdog — restart, verify, and escalate only if recovery fails:
$service = "Spooler"
if ((Get-Service -Name $service).Status -ne "Running") {
Restart-Service -Name $service -Force
Start-Sleep -Seconds 10
}
if ((Get-Service -Name $service).Status -eq "Running") {
Write-Output "$service recovered after automated restart"
} else {
Write-Output "$service still down after restart - escalating to on-call"
exit 1
}
On Linux — including an Asahi box on M3 hardware — trim the systemd journal before it quietly fills the root volume, the same way it does on every distro:
#!/bin/bash
used=$(df --output=pcent / | tail -1 | tr -dc '0-9')
if [ "$used" -ge 90 ]; then
journalctl --vacuum-size=500M
echo "Journal trimmed. Current usage:"
df -h /
fi
Step 3: Attach the scripts as runbooks in AlertMonitor. Under Alerts → Runbooks, bind each script to its alert condition and set the escalation policy: page only on a non-zero exit code, or if the same condition fires three times in 24 hours — that's your flap detector telling you the runbook is treating a symptom, not the cause.
Step 4: Canary everything. Before any fleet-wide push — script, agent update, or patch — target a pilot ring of 5–10 devices spread across your sites, OS builds, and hardware generations. AlertMonitor compares success rates and error events on the ring against the fleet baseline and holds the rollout if anything regresses. Only then does it go wide.
Step 5: Let the loop write your budget case. Every automated remediation lands on the device timeline. At the end of the month, your "self-healed incidents" report — X issues fixed before a human ever saw them, Y hours saved, Z tickets never created — is the clearest proactive-IT argument you will ever put in front of a CFO.
The Takeaway
The Asahi Linux team shipping M3 support with known gaps is honest engineering: most of it works, and they'll tell you exactly which parts don't. That's also the honest state of every production environment you manage. Partial support, quiet regressions, and soft failures aren't exceptions. They're the job.
The teams that handle it well don't have fewer failures. They have shorter loops between detection and resolution — loops that close themselves most of the time. Attach runbooks to your alerts. Canary every rollout. Keep monitoring, RMM, helpdesk, and patching on one timeline. With AlertMonitor, proactive IT stops being the goal and becomes the norm.
Related Resources
AlertMonitor Self-Healing & Proactive IT AlertMonitor Platform Overview Book a Demo Self-Healing & Proactive IT Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.