Invoice Tennis, Expired Credits, and a $17,600 Blind Spot: What Real-Time Visibility Actually Requires

The Story Every IT Team Knows

The Register recently reported on Vegalabs, a startup that ended up with a $17,600 bill for Claude usage billed through the Azure Marketplace — while $21,168 in prepaid Azure credits sat unused and expired. Marketplace charges piled up on one invoice while prepaid credits burned down toward expiry on another. When Vegalabs asked for help, Microsoft pointed at Anthropic. Anthropic pointed back at Microsoft. The Register called it invoice tennis. Two of the largest vendors in the industry, and neither one — nor the customer — had a single, current, joined-up view of what was being consumed, what had been pre-paid, and what was about to expire.

If you run infrastructure for a living, you have lived a version of this. Maybe it wasn't a $17,600 invoice. Maybe it was a dead access-layer switch in a branch closet that nobody heard about until 14 users filed tickets. Maybe it was an IP camera system on the same VLAN as your workstations that nobody ever inventoried. The pattern is identical: the truth existed in one system, was invisible in the four or five tools your team actually uses, and was discovered only after the damage was done.

The Problem in Depth: Visibility Rented Out in Pieces

Look at how the Vegalabs situation was structured, because it maps almost one-to-one onto how most IT departments still operate:

• API consumption lived in one place (Anthropic usage, billed via Azure Marketplace)
• Prepaid credits lived in another (Azure billing, tracked somewhere in procurement email)
• Expiry dates lived nowhere — until they expired

Now swap in network operations terms:

• Agent status lives in your RMM (NinjaOne, ConnectWise, Datto)
• SNMP up/down and bandwidth graphs live in a standalone monitor (PRTG, SolarWinds)
• The network map lives in a Visio diagram last touched 18 months ago
• Tickets live in a separate helpdesk that never hears from the monitor

Each tool was designed for its own slice of the world, and each holds a partial truth. Nobody designed the join. Discovery, where it exists at all, is a quarterly scan or a one-time onboarding project — so your map of the network is a photograph of the past. You are making decisions from stale data, and you find out about the present the way Vegalabs found out about the credits: when it is already expensive.

What This Costs in Real Terms

• The silent switch failure. Your standalone monitor polls the core router, so when an access switch in a closet dies, nothing fires. Users can't reach the ERP. Fourteen tickets land in 20 minutes. A tech spends 45 minutes tracing cables because the diagram doesn't show which uplink port that switch uses. MTTR: two hours. This happens every week in IT shops that believe they have monitoring.
• The network you don't actually know. Run a real discovery sweep against almost any site and you'll find more devices than the contract says. We routinely hear variants of: the contract covers 200 endpoints, discovery found 240. Printers nobody manages, IP cameras on the workstation VLAN, a consumer Wi-Fi AP under a desk. Every one of them is unmonitored, unsupported, and unbudgeted.
• Money burning quietly. Unused credits expiring ($21,168 in Vegalabs' case), a dev subscription charging Marketplace services no one remembers enabling, a forgotten backup VM in a test resource group. Finance discovers these at invoice time — the exact same failure mode as discovering the dead switch from a user's phone call.
• People burning quietly. Technicians paged by users instead of tools. The IT manager who can't produce an accurate SLA report because alert timestamps live in the monitoring tool and resolution timestamps live in the helpdesk, and nothing joins them. The MSP tech with 12 tabs open across five consoles to support one client. That's how burnout happens: not from hard problems, but from preventable ones wearing you down.

Why the Gaps Exist

Siloed architecture and legacy design. RMM platforms were built around agent check-ins on Windows endpoints. Standalone network monitors were built around poll-and-graph of devices you manually added by IP. Helpdesks were built around ticket queues. All three categories predate the expectation that one platform should know your entire environment continuously and tell you the moment it changes. The seams between the tools become the blind spots — and the blind spots are exactly where surprise bills, silent outages, and shadow devices live.

How AlertMonitor Closes the Gap

AlertMonitor treats discovery and mapping as a continuous process, not a project:

• Continuous network discovery via SNMP, ARP, and active scanning. Switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints are found automatically as they appear — not at the next quarterly audit.
• A live topology map that reflects the network as it is right now. When a switch goes offline, a link drops, or a new device appears, an alert fires instantly with full context: which device, which port, what's downstream, which users are impacted.
• New-device alerts catch unauthorized or unmanaged gear the moment it joins the network — the network equivalent of catching a runaway cloud resource before the invoice lands instead of after.
• One platform, one alert stream. Monitoring, RMM, helpdesk, patch management, and topology live in the same product, so a device-down alert auto-creates a ticket pre-populated with topology context. The tech starts at the failing port, not at have-you-tried-rebooting-it.
• A multi-client NOC dashboard for MSPs: every client's live map and alert stream in one console, instead of five tools and a browser on fire.

The workflow difference, concretely:

Before: User calls → ticket → remote session → agent looks fine → the standalone monitor doesn't even have that switch in it → someone digs up the Visio → the Visio is wrong → physically trace cables → find the dead switch → swap it. Two-plus hours, fourteen angry users, one exhausted tech.

With AlertMonitor: Switch drops → topology alert fires within seconds with device, port, and downstream impact → ticket auto-created with that context → tech confirms failure and dispatches → users proactively notified. Minutes, not hours.

That is also what an accurate SLA report finally looks like: alert time, acknowledge time, resolution time — one dataset, because the monitor and the helpdesk are the same system.

What You Can Do Today

You don't have to wait for a platform to start closing the visibility gap. Run these checks this week.

1. See what's actually on the wire. Pull the ARP table from a core machine and look at every IPv4 neighbor it has talked to:

# List every reachable IPv4 neighbor this machine has talked to
Get-NetNeighbor -AddressFamily IPv4 |
    Where-Object { $_.State -in 'Reachable','Probe','Stale' } |
    Sort-Object IPAddress -Unique |
    Select-Object IPAddress, LinkLayerAddress, State |
    Format-Table -AutoSize

2. Reconcile it against your inventory. Anything in ARP but not in inventory is either a new deployment nobody told you about, shadow IT, or a device you're contractually supporting but can't see:

# Compare live ARP entries against your inventory export (needs an IPAddress column)
$inventory = Import-Csv "C:\audit\inventory.csv"
$knownIPs  = $inventory.IPAddress

$live = (Get-NetNeighbor -AddressFamily IPv4 -State Reachable,Probe,Stale |
         Select-Object -ExpandProperty IPAddress) | Select-Object -Unique

$unknown = $live | Where-Object { $knownIPs -notcontains $_ }
"Discovered devices not in inventory: $($unknown.Count)"
$unknown

3. Do the same from your Linux boxes:

# Show the kernel neighbour (ARP) table, excluding failed entries
ip neigh show | grep -v FAILED | sort -k1

# Or run an active sweep of a /24 and list the live hosts
nmap -sn 192.168.10.0/24 -oG - | awk '/Up$/{print $2}'

4. Audit your cloud spend before it becomes invoice tennis. The Vegalabs bill piled up while credits expired unused — this is the 30-minute check that catches that pattern:

# Top Azure meter categories by cost over the last 30 days
# Requires: Install-Module Az -Scope CurrentUser
Connect-AzAccount
$start = (Get-Date).AddDays(-30).ToString("yyyy-MM-dd")
$end   = (Get-Date).ToString("yyyy-MM-dd")

Get-AzConsumptionUsageDetail -StartDate $start -EndDate $end |
    Group-Object { $_.MeterDetails.MeterCategory } |
    Select-Object Name,
        @{ n = 'CostUSD'; e = { [math]::Round(($_.Group | Measure-Object PretaxCost -Sum).Sum, 2) } } |
    Sort-Object CostUSD -Descending

Then do the unglamorous manual items: diarize every credit and reservation expiry with 60- and 30-day reminders, verify auto-shutdown on dev/test resources, and put a named owner on every Marketplace subscription. These are exactly the items that fell through the cracks at Vegalabs, and exactly the items no vendor will track for you — as the tennis match proved.

5. Then stop doing it manually. The scripts above only tell you what changed since the last time you remembered to run them. AlertMonitor's continuous discovery (SNMP + ARP + active scanning) runs that reconciliation constantly, keeps the topology map live, and fires new-device, offline, and link-down alerts with full network context automatically — per site for internal teams, per client for MSPs.

The Takeaway

Vegalabs' $17,600 bill and your next undetected switch failure are the same story: fragmented visibility, stale data, and discovery after the damage. Microsoft and Anthropic played invoice tennis because neither held — or shared — the full picture. Your tools play the same game whenever the RMM, the monitor, the map, and the helpdesk each hold a piece and nothing joins them.

You don't have to operate that way. One live map. One alert stream. One place where monitoring, helpdesk, and network context already agree. That's what turns we-found-out-from-the-users into we-fired-the-alert-before-anyone-noticed.

Related Resources

AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources