VS Code Agents Now Merge Pull Requests — So Why Do You Still Learn About Server Failures From User Tickets?

Microsoft shipped Visual Studio Code 1.136 on September 2, and the feature that should make every IT operations team a little jealous is Agent Merge. It's in preview (enable it with the chat.agentMerge.enabled setting), and it hands a struggling pull request to an AI agent that addresses review feedback, fixes failed checks and merge conflicts, and reruns workflows until the PR is ready to merge. The agent loops — check, fix, verify, repeat — and only escalates when a human genuinely needs to step in.

That is the new bar for tooling: detect the problem, act on it, verify the fix, close the loop.

Now compare that to how most IT teams still learn about a production problem: a user opens a ticket because the file share feels slow. Helpdesk triages it, assigns it, a tech remotes in and pokes around. Forty minutes after the disk actually crossed 90%, someone finally opens Server Manager. Developers just got an agent that closes their loop automatically. Meanwhile, your monitoring stack still can't reliably close the loop between metric went bad and right person is fixing it.

If that stings a little, this post is for you.

The Problem: Your Monitoring Is Five Tools That Don't Talk to Each Other

Walk through a typical mid-size IT shop — or an MSP's dashboard for a single client — and count what's installed on one Windows Server:

• An RMM agent (NinjaOne, ConnectWise Automate, Datto RMM) for patching and remote access
• A separate uptime checker (Pingdom, UptimeRobot) pointed at the public-facing endpoints
• A standalone monitoring tool (PRTG, Zabbix, Datadog) for servers, services, and apps
• A log collector nobody has tuned since onboarding
• A helpdesk platform (ConnectWise Manage, HaloPSA, Freshservice) that only hears about incidents through email-to-ticket parsing rules

Each tool has its own polling interval, its own threshold model, its own alert destination, and its own definition of "critical." None of them share state. The monitoring tool doesn't know a ticket exists. The helpdesk has no idea which alert fired. The RMM could fix the problem, but it was never told about it.

Why does this happen? These are point solutions accumulated over years, each built on a siloed architecture with its own data model. The "integration" between them is brittle glue: an email rule here, a webhook there — webhooks that fail silently and go unnoticed for weeks, because ironically, nothing monitors the monitoring.

What it actually costs you:

• Late detection. A static 95% disk threshold on a 15-minute poll means the PRINT01 spooler volume can sit at 94% for days, then blow past the line during a Tuesday morning print storm. By the time the poll catches it, spooled jobs and Windows Update cache have filled the drive and users are already ticketing.
• Slow acknowledgment. The alert lands in a shared mailbox. At 2 PM on a Friday, who's watching? Your MTTA is measured in coffee breaks, not seconds.
• Ticket pileups. One real incident generates six tickets from six annoyed users. Two techs work duplicates while a third chases a different symptom of the same fire.
• Dishonest SLA reporting. The helpdesk clocks response time from ticket creation, not from when the incident actually began. Your reports look fine. Your users disagree. And because monitoring data and ticket data live in separate systems, you can't even prove what really happened.
• Burnout. Alert fatigue is real. When a noisy uptime tool pages you at 2 AM for a false positive while the real 2 AM problem — a failed nightly backup on the SQL box — pages nobody, technicians stop trusting the tooling.

That last one is the expensive one. A monitoring stack your team doesn't trust is functionally the same as having no monitoring at all — you've just paid more for it.

How AlertMonitor Closes the Loop

Agent Merge works because one system can see the checks, the conflicts, and the workflows — and act on all of them. That's exactly the principle behind AlertMonitor, applied to infrastructure instead of code.

One agent, one pane of glass. A single lightweight agent covers Windows and Linux servers, Windows workstations, applications, Windows services, and scheduled tasks — with real-time metric streaming instead of 15-minute polls. Network topology mapping ties it together, so when PRINT01 goes down you see which departments and downstream services are affected, not just that a host is unreachable.

Real-time alerting that routes to a person, not a mailbox. When a disk crosses your threshold or a critical service dies, AlertMonitor pages the right person in seconds — mobile push, email, escalation chains with automatic handoff if nobody acknowledges. No more "the alert was in the shared inbox."

Alerts become tickets with full context. Because the helpdesk is built in, an alert opens a ticket pre-populated with the host, the metric history, and what changed. No email parsing, no tech asking "which server was that again?"

Remediate without switching tools. RMM is part of the platform. From the alert itself, restart the service, run a script, kick off the fix. Alert → action → verification happens in one console — the same closed loop Agent Merge runs on a pull request.

Patch state is right there. When that disk is filling with update caches, you can see patch compliance from the same screen instead of opening a fifth tab.

The outcome a real team feels: an incident that used to take 40 minutes to discover and 20 minutes to triage now gets detected in seconds and acknowledged in under two. Duplicate tickets collapse because the first ticket already carries full context. SLA reports reflect actual incident start times. And on-call techs answer their pages — because the pages are worth answering.

Practical Steps You Can Take Today

Before you change any tooling, find out what's silently broken right now. Run these across your estate — each one surfaces the exact class of failure that users report before IT knows anything is wrong.

1. Find auto-start services that silently stopped — the classic "no alert fired, users noticed" failure:

Get-CimInstance -ClassName Win32_Service -Filter "StartMode='Auto' AND State!='Running'" |
  Select-Object Name, DisplayName, State, StartMode, ExitCode |
  Format-Table -AutoSize

2. Baseline disk space across your servers — know which volumes are trending toward trouble before they get there:

$servers = "FS01","SQL01","PRINT01","APP01"
Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter "DriveType=3" -ErrorAction SilentlyContinue |
  Select-Object @{n='Server';e={$_.PSComputerName}}, DeviceID,
    @{n='SizeGB';e={[math]::Round($_.Size/1GB,1)}},
    @{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
    @{n='FreePct';e={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}} |
  Where-Object { $_.FreePct -lt 15 } |
  Sort-Object FreePct

3. Audit scheduled tasks that failed on their last run — failed backups and maintenance scripts are the incidents nobody notices until restore time:

Get-ScheduledTask | Where-Object { $_.State -ne 'Disabled' } | ForEach-Object {
  $info = $_ | Get-ScheduledTaskInfo
  if ($info.LastTaskResult -ne 0 -and $info.LastRunTime -gt (Get-Date).AddDays(-1)) {
    [PSCustomObject]@{
      Task    = "$($_.TaskPath)$($_.TaskName)"
      LastRun = $info.LastRunTime
      Result  = $info.LastTaskResult
    }
  }
} | Format-Table -AutoSize

4. Same discipline on your Linux boxes — flag any filesystem at 85% usage or higher:

df -h -x tmpfs -x devtmpfs | awk 'NR==1 || substr($5, 1, length($5)-1)+0 >= 85'

Then make three structural changes:

5. Kill email-only alerting. Every critical alert needs a routing rule: who gets paged, how, and what happens if nobody acknowledges within five minutes. In AlertMonitor, that's an escalation policy on the alert profile — define it once, per severity, and stop praying someone reads the shared inbox.

6. Wire monitoring directly to the helpdesk. Alerts should create tickets automatically, with host and metric history attached. Once that's in place, your SLA data finally reflects incident start time instead of ticket creation time — and duplicate tickets drop because the first ticket already tells the whole story.

7. Map the blast radius. Put your servers on the network topology map so the next outage announcement says which departments are impacted — before the phone rings, not after.

The Takeaway

VS Code 1.136's Agent Merge is a glimpse of where tooling is headed: software that doesn't just tell you something failed, but pushes the work toward done. Your development counterparts have that now. Your infrastructure deserves the same standard — one platform that detects, routes, tickets, and helps you fix, instead of five tools that each know a piece of the story and tell no one.

Your users will notice the difference first. That's the point — they shouldn't have to.

Related Resources

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