GitHub Copilot Metrics Now Name Custom Agents: The Observability Lesson Your Server Monitoring Needs

GitHub shipped a change this week that looks like developer-tool housekeeping and is actually a masterclass in operational visibility: the Copilot usage metrics API now identifies custom agents, skills, MCP servers, slash commands, and plugins by their configured names — with up to 25 named entries per category, up from five.

If you run infrastructure for a living, read that and feel a little called out. Because the exact principle that pushed GitHub to improve its reporting — a metric without a name can't be acted on — is the same principle that separates IT teams who resolve incidents in minutes from teams who find out about outages from a ticket that says "the server is slow."

What GitHub Actually Changed

GitHub's usage metrics API gives organizations aggregated reporting on how developers use Copilot. The problem was anonymity: if your company deployed eight custom agents and a dozen MCP integrations, the report lumped most of that activity into a handful of unnamed entries. "Something" used a custom agent 400 times this month. Which one? Did the finance team's invoice-extraction agent get adopted, or is everyone still using the generic assistant?

The update fixes that: reports now name each agent, skill, MCP server, slash command, and plugin by its configured name, and they surface up to 25 named entries per category instead of five. An IT manager can finally see adoption per tool and act on it.

Notice what GitHub did NOT do: they didn't collect new data. They made existing data nameable. That's the entire difference between a dashboard you glance at and an alert you can resolve.

The Problem: Your Monitoring Is Probably Still Anonymous

Here's the uncomfortable parallel. GitHub had usage data but couldn't tell customers what the data referred to. Plenty of IT shops have monitoring data with the same failure — or worse, have no monitors where it matters at all. Three patterns show up in almost every environment I audit:

1. The things most likely to fail have no monitor

Your RMM or monitoring tool watches CPU, RAM, disk, and ping out of the box. What it usually doesn't watch:

• The third-party vendor integration service that wedges itself every Tuesday and just... keeps running, uselessly
• The nightly ETL or backup job whose non-zero exit code nobody checks
• The report scheduler task that's been failing since a Windows Update in March

These fail silently. No CPU spike, no service-crash event — just a task that returns exit code 1 at 2:15 a.m. into a log nobody reads. The discovery mechanism, in practice, is an end user at 8:37 a.m. opening a ticket titled "invoices aren't generating." Congratulations: your mean time to detect is now "whenever a user notices."

2. The alerts that do fire are context-free

When an alert does fire, it often reads like SRV-APP-04: Disk C: 92% used. Great. Filled by what? SQL Server log growth? A stuck IIS log directory? A WSUS update cache nobody has cleaned since 2022? The tech now opens the RMM, RDPs into the box, runs a manual check, and pokes around in Explorer — ten minutes spent just figuring out what the alert was actually about. And if your helpdesk is a separate product (ConnectWise Manage, Freshservice, ServiceNow), the ticket gets created with none of that monitoring context, so someone re-types it at 2 a.m.

3. Tool sprawl multiplies the blindness

The typical mid-size IT shop runs something like this: NinjaOne or Datto RMM for endpoints, PRTG or UptimeRobot for uptime, a separate helpdesk, WSUS or the RMM patch module for updates, and plain Remote Desktop for actual work. Five tools, twelve tabs, zero shared timeline. For an MSP it's worse — multiply that stack by 25 clients, each with its own quirks and its own alert-routing rules that live in one senior tech's head.

What this costs, in numbers you'll recognize

• Detection: 30–45 minutes between failure and the first user ticket is typical when coverage has gaps. That's dead time added to every single incident.
• MTTR: troubleshooting doesn't start until detection ends. A 20-minute fix becomes a 60-minute outage.
• SLA reporting: try producing an accurate response-time report when ticket timestamps live in the helpdesk and outage timestamps live in the monitoring tool. You can't — so you estimate, and estimates don't survive a client QBR.
• Morale: alert storms of unnamed, low-context noise train your on-call tech to swipe pages away — until they swipe away the one that actually matters.

How AlertMonitor Puts a Name on Every Failure

This is precisely the gap AlertMonitor was built to close: one platform, one alert stream, and every alert carrying the context a tech needs to act immediately.

• Unified coverage. Servers, Windows services, applications, workstations, scheduled tasks, and network devices are monitored in one place — so the vendor integration service and the nightly ETL job are first-class citizens, not afterthoughts you script around.
• Named, specific alerts. When a disk hits 90%, the alert names the server and volume. When a critical Windows service crashes, it names the service and host. When a scheduled task fails, it names the task and its exit code. No anonymous entries.
• Intelligent escalation. The alert routes to the person who owns that service or client within seconds — not to a shared inbox checked after lunch.
• Monitoring → helpdesk in one motion. An alert becomes a ticket with its monitoring context attached. Nobody copy-pastes details between a monitoring console and a helpdesk form in the middle of the night.
• RMM and patching in the same pane. Disk mysteriously full? Check the patch state and update cache of that same machine without switching tools. Suspect a bad update? Patch history is right there in the incident view.
• One NOC view for MSPs. Every client's entire stack in a single dashboard with per-client views and routing — instead of one set of tabs per client.

The old way: disk fills at 2:00 a.m. → that volume isn't covered → 2:40 a.m. first user ticket → tech opens the RMM to confirm → RDP in → manual cleanup → manually update the ticket → SLA already blown. Elapsed: 90+ minutes.

With AlertMonitor: threshold breach detected in seconds → on-call tech paged with server, volume, and severity → ticket auto-created with context → remote session launched from the same platform → resolved before the office opens. Elapsed: minutes.

Practical Steps: Audit Your Anonymous Blind Spots Today

Before you change any tooling, find out what is silently failing right now. These scripts take ten minutes to run and reliably produce an "oh no" moment.

1. Find auto-start services that aren't running

$servers = Get-Content .\servers.txt

foreach ($srv in $servers) {
    Get-CimInstance -ClassName Win32_Service `
        -Filter "StartMode='Auto' AND State != 'Running'" `
        -ComputerName $srv |
        Select-Object @{n='Server';e={$srv}}, Name, DisplayName, State, StartName |
        Format-Table -AutoSize
}

Every row this returns is a service configured to start but not running — and if it isn't in your monitoring, your users will find it before you do.

2. Sweep disk usage and name the worst offenders

$threshold = 90

Get-CimInstance -ClassName Win32_LogicalDisk -Filter "DriveType=3" `
    -ComputerName (Get-Content .\servers.txt) |
    ForEach-Object {
        $usedPct = [math]::Round((($_.Size - $_.FreeSpace) / $_.Size) * 100, 1)
        if ($usedPct -ge $threshold) {
            [PSCustomObject]@{
                Server  = $_.PSComputerName
                Volume  = $_.DeviceID
                UsedPct = $usedPct
                FreeGB  = [math]::Round($_.FreeSpace / 1GB, 1)
            }
        }
    } | Sort-Object UsedPct -Descending

3. Check last night's scheduled tasks for failures

Exit code 267009 (0x41301) just means "still running" — everything else non-zero deserves a look.

foreach ($srv in Get-Content .\servers.txt) {
    $session = New-CimSession -ComputerName $srv
    Get-ScheduledTask -CimSession $session |
        Where-Object State -ne 'Disabled' |
        ForEach-Object {
            $info = $_ | Get-ScheduledTaskInfo -CimSession $session
            if ($info.LastTaskResult -notin 0, 267009 -and
                $info.LastRunTime -gt (Get-Date).AddDays(-1)) {
                [PSCustomObject]@{
                    Server   = $srv
                    Task     = $_.TaskName
                    LastRun  = $info.LastRunTime
                    ExitCode = $info.LastTaskResult
                }
            }
        }
    Remove-CimSession $session
}

4. The same idea on Linux

#!/bin/bash
# Volumes over 90% full
df -h -x tmpfs -x devtmpfs | awk 'NR>1 && $5+0 >= 90 {print "WARNING:", $6, "is", $5, "full"}'

# systemd units that failed to start in the last 24 hours
journalctl --since "24 hours ago" --no-pager |
    grep "Failed to start" |
    sed -E 's/.*Failed to start //' |
    sort | uniq -c | sort -rn

5. Turn snapshots into named, continuous monitoring

The scripts above are point-in-time snapshots. The GitHub lesson is that this telemetry should be continuous and nameable. In AlertMonitor, each of these checks becomes a monitored condition per server or per client, and every resulting alert carries the name of the exact thing that failed — the service, the task, the volume, the host — routes to the right person in seconds, and opens a ticket with context attached. No "something on SRV-APP-04," no anonymous entries, no re-typing details into a helpdesk.

The Takeaway

GitHub didn't invent new telemetry for Copilot — it made existing telemetry specific enough to act on, and raised the named-entry cap from 5 to 25 because five wasn't enough to describe reality. Audit your own alerting with that same lens: how many of your monitors would fire tonight, and how many of those alerts would tell the on-call tech exactly what broke, on which server, and who owns it? If the honest answer is "not enough," your metrics are anonymous — and anonymous metrics are how a 20-minute fix becomes a 90-minute outage discovered by a user ticket.

Related Resources

AlertMonitor Infrastructure & Server Monitoring AlertMonitor Platform Overview Book a Demo Infrastructure & Server Monitoring Resources