Starliner Gets Another Shot at the ISS. Your Missed SLA Doesn't: The Fleet Readiness Checklist Every MSP Needs

One Failed Mission, Two Years in the Hangar

The Register is calling Boeing's Starliner the "Calamity Capsule," and honestly, the nickname is earned. After thruster failures and helium leaks turned the crewed flight test into a months-long saga — NASA astronauts eventually rode home on a SpaceX vehicle while Starliner came back empty — the program went back to the hangar. Now Starliner-1 could fly as early as January, with astronauts to follow by 2028 if all goes well.

Read that timeline again: one bad mission, roughly two years of recovery. And the recovery only works because aerospace operations run on a discipline most IT shops have never adopted:

• Every component has telemetry. Nothing is "probably fine."
• Every mission gets a readiness review. Nothing flies until every system is verified.
• Every failure triggers fleet-wide root cause analysis. One thruster anomaly grounds the entire fleet until the failure is understood and fixed everywhere.

Now contrast that with how most MSPs run mission-critical infrastructure for dozens of clients. No readiness review. Telemetry scattered across five tools that don't talk to each other. "Probably fine" as the default posture, verified only when a client calls.

Boeing gets a second launch window. When a client's file server dies at 9 a.m. on a Monday because a disk filled up over the weekend and nobody got a useful alert, you don't get a second window. You get a churned contract and a one-star review.

The Problem: Telemetry Everywhere, Mission Control Nowhere

If you run or staff an MSP NOC, this morning will feel familiar.

The 12-Tab Health Check

Your tech starts the day trying to answer one question: "Are all my clients OK?" To answer it, they open:

1. The RMM (ConnectWise, Ninja, Syncro) — agent statuses, maybe a glance at patch status
2. A standalone monitoring tool (PRTG, SolarWinds, Zabbix) — because the RMM's network monitoring isn't trusted
3. The PSA/helpdesk (ConnectWise Manage, Autotask, HaloPSA) — what tickets came in overnight?
4. The backup console (Veeam, Acronis) — a separate tab, because of course it is
5. A spreadsheet — the glue holding it all together

Twelve tabs, five logins, forty minutes before they know whether anything is on fire. And the answer is still probably wrong, because:

• "Online" doesn't mean "healthy." The RMM shows the machine checked in this morning. It does not show that the backup agent has been quietly failing for three weeks, or that a critical service is stopped and nobody noticed because the app "tolerates it for now."
• Alerts go where tickets don't. The disk alert fired at 2 a.m. Saturday — to an email distribution list monitored by no one since the last tech left. No ticket was created. The SLA clock doesn't start until the client calls at 9:04 a.m. Monday. On paper you "responded within SLA." In reality you had 55 hours of notice and used none of it.
• Patch reporting is a manual art project. Export patch status to CSV from the RMM, cross-reference the client asset list in Excel, highlight outliers, build a per-client compliance report. Now multiply by 40 clients, every month. That's a full tech-day per month producing reports that were stale before they were emailed.

Why the Gaps Exist

These tools were never designed together. Monitoring was bolted onto RMMs. Ticketing lived in a separate PSA because that's how it was licensed in 2010. Integration — where it exists at all — is a fragile webhook and a prayer: when the API changes, alerts silently stop creating tickets, and nobody notices until an SLA miss surfaces it. Per-seat licensing makes it worse: if putting the whole overnight team into the monitoring console costs an extra few thousand a year, the unmonitored email distro stays as the "free" option — and it costs you the client instead.

The business impact, in terms a service manager recognizes immediately:

• Detection isn't the bottleneck; handoffs are. The disk hit 90% at 2 a.m. The data existed. Moving it from monitoring to ticket to technician to remediation took 55 hours because a human had to shuttle it between systems.
• Context switching burns hours per tech per day. Fifty tool jumps a shift, each one a re-authentication, a context reload, a re-orientation. That's a third of the day spent navigating software instead of resolving incidents.
• Morale bleeds out through missed alerts. Nothing demoralizes a good technician faster than discovering a problem the tools knew about but never surfaced where the work actually happens.

How AlertMonitor Collapses the Workflow

AlertMonitor was purpose-built for the MSP model, and the difference shows up at exactly these failure points.

One Record, Start to Finish

In AlertMonitor, a disk alert on a client server doesn't fire an email into the void. It appears on the unified NOC dashboard with client context attached, auto-creates a ticket routed to the right queue, and starts that client's SLA clock immediately. The alert, the ticket, and the device share one timeline, so any technician who picks it up sees the full history. From the ticket they open a remote session — remediation starts in seconds, not after another tool launch. Then the loop closes: disk cleaned or patch applied, a verification check confirms recovery, and the ticket resolves with evidence attached.

Detect, diagnose, fix, verify — on a single record. That's the aerospace loop — telemetry, root cause, correction, verified recovery — applied to every ticket instead of reserved for post-mortems.

Multi-Tenant From Day One

This is what generic monitoring tools get wrong and MSPs can't compromise on:

• Isolated per-client dashboards — each client sees their environment, never anyone else's infrastructure
• Per-client alert routing — Client A's critical alerts page the on-call tech; Client B's go to email during business hours; no manual filtering, no forgotten distro lists
• Per-client SLA thresholds — your Platinum client gets a 15-minute response target, your standard managed client gets four hours, and the platform tracks both accurately instead of averaging them into a meaningless number
• A unified NOC view across all clients simultaneously — the 12-tab morning ritual becomes one screen, sorted by severity, showing exactly which of your 40 clients needs attention first

Consolidation That Shows Up in the P&L

Monitoring, RMM, helpdesk, network topology mapping, and patch management live in one platform with one licensing model. That means dropping the standalone monitoring tool, the per-seat console licenses, and — let's be honest — the spreadsheet. Technicians stop paying the tool-switching tax and start resolving tickets. The patch compliance report that consumed a tech-day per month becomes a filtered dashboard view you export in two minutes.

Practical Steps: Build Your Daily Pre-Flight, Starting This Week

You don't need a platform migration to start running readiness checks. Here's the checklist.

1. Define "Flight-Ready" Per Client

Write down, per client tier, what must be true every morning:

• All monitoring agents checked in within the last 24 hours
• Patch compliance above your threshold (e.g., 95%)
• No pending reboots older than 7 days
• Business-critical services running
• Backups completed successfully
• All server volumes above your free-space floor

2. Sweep for Pending Reboots

This is the number-one reason "we patched, but the fix isn't applied": the update installed but never activated. Sweep every server:

$servers = Get-Content 'C:\MSP\reports\servers.txt'
$report = foreach ($server in $servers) {
    $state = Invoke-Command -ComputerName $server -ScriptBlock {
        if (Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending') { 'RebootPending' }
        elseif (Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired') { 'RebootRequired' }
        else { 'Clear' }
    }
    [PSCustomObject]@{ Server = $server; RebootState = $state; Checked = (Get-Date) }
}
$report | Sort-Object RebootState -Descending |
    Export-Csv 'C:\MSP\reports\reboot-readiness.csv' -NoTypeInformation

Any RebootPending row is a patch installed but never activated. In AlertMonitor this becomes a scheduled per-client check that alerts and auto-tickets — not a manual sweep someone has to remember to run.

3. Check Disk Space Before the Client Calls

The classic overnight failure. Check the free-space floor instead of waiting for the 90% threshold that fires too late:

$freeFloorGB = 20
$servers = Get-Content 'C:\MSP\reports\servers.txt'
Invoke-Command -ComputerName $servers -ScriptBlock {
    Get-CimInstance -ClassName Win32_LogicalDisk -Filter 'DriveType=3'
} | ForEach-Object {
    [PSCustomObject]@{
        Server = $_.PSComputerName
        Drive  = $_.DeviceID
        FreeGB = [math]::Round($_.FreeSpace / 1GB, 1)
        SizeGB = [math]::Round($_.Size / 1GB, 0)
    }
} | Where-Object { $_.FreeGB -lt $freeFloorGB } |
    Sort-Object FreeGB | Format-Table -AutoSize

Silent output means the fleet is clean. Rows mean you just found next Monday's emergency before it became one.

4. Verify the Services That Actually Matter

Don't check that the box is up. Check that the services your client's business depends on are running:

$critical = @('Netlogon','DFSR','wuauserv')  # trim per client — add SQL, print, app services
$servers = Get-Content 'C:\MSP\reports\servers.txt'
Invoke-Command -ComputerName $servers -ScriptBlock {
    Get-Service -Name $using:critical -ErrorAction SilentlyContinue |
        Where-Object Status -ne 'Running' |
        Select-Object Name, DisplayName, Status
} | Select-Object PSComputerName, Name, DisplayName, Status | Sort-Object PSComputerName

For the Linux side of the fleet:

#!/bin/bash
# Readiness sweep: disk usage and failed units on every Linux host
for host in $(cat /opt/msp/linux-servers.txt); do
    echo "=== $host ==="
    ssh -o ConnectTimeout=5 "$host" '
        df -h --output=target,pcent / | tail -n +2
        systemctl list-units --state=failed --no-legend --no-pager
    '
done

5. Move Every Script From Manual Sweep to Continuous Check

The scripts above make you ready today. AlertMonitor makes you ready every day: deploy them as scheduled checks per client, threshold the results, auto-ticket the failures, and route the alerts by that client's SLA. The manual sweep becomes a dashboard tile. The readiness review runs continuously — whether or not anyone remembers to trigger it.

6. Run the Morning Standup Off One Screen

Five minutes, every day: open the unified NOC view, sort by severity and SLA state, triage what's red. No exports, no cross-referencing, no "let me check the other tool." One screen, every client, real data.

Second Chances Are for Aerospace

Boeing will spend years and a very large budget verifying that Starliner is fit to fly again — and that's the right way to run a spacecraft program. But your MSP doesn't have a NASA budget, and your clients' tolerance for a failed mission is measured in hours, not launch windows.

The lesson worth stealing from aerospace isn't the money. It's the loop: telemetry on everything, verification before you declare victory, and a root-cause process that turns one failure into fleet-wide improvement. AlertMonitor gives you that loop across every client, on every ticket, every day — in one platform your whole team can afford to live in.

Because the next disk-full alert doesn't need a two-year recovery program. It needs to become a ticket in seconds, get fixed in one remote session, and close with verified recovery before the client ever knows something happened.

Related Resources

AlertMonitor MSP Operations & Team Efficiency AlertMonitor Platform Overview Book a Demo MSP Operations & Team Efficiency Resources