Cloudflare's Clairic Just Proved a Point About Your Network Data
Cloudflare just opened a preview of Clairic, a new model on Workers AI. Unlike a chatbot, Clairic doesn't generate free-form answers — it extracts, calculates, estimates, and forecasts typed values: dates, amounts, durations. Schema-bound output. Confidence data attached. Single-pass execution for lower latency and cost, with open weights planned.
Why should a network monitoring blog care about an extraction model? Because Clairic is the industry admitting something every burned-out sysadmin already knows: unstructured input produces unreliable output. Cloudflare built a model that refuses to guess.
Now look at the data your IT team uses to run the network. A Visio diagram last touched during the 2023 audit. An inventory spreadsheet on SharePoint that three people edit and nobody trusts. A discovery scan that runs Sunday nights, so anything plugged in on Monday doesn't exist until next week. Tribal knowledge from the sysadmin who left in March.
Your network documentation is the exact opposite of Clairic: unstructured, unverified, and months out of date. Meanwhile, your on-call tech gets paged at 2 a.m. because a poller saw a device die — and spends the next hour figuring out which floor that switch is even on. Every alert, every response decision, and every SLA report downstream inherits that rot.
This post breaks down what stale network data actually costs you in real incidents — and how live, continuously discovered topology fixes it.
The Problem: Discovery Is a Scheduled Job, Not a Live Feed
What your current stack actually knows
Be honest about what each tool in the stack knows about the network:
- Your SNMP poller (PRTG, SolarWinds, LibreNMS) knows that
10.10.1.5went down. It has no idea that 38 users, the front-desk printer, and two VoIP phones hang off that access switch. - Your RMM (NinjaOne, ConnectWise Automate, Datto RMM) knows every agent-installed endpoint's patch level. It knows nothing about the unmanaged switch in the supply closet, the IP camera a vendor added, or which uplink just flapped.
- Your helpdesk knows a user named Dana reported "no internet." It cannot see that Dana's entire floor is downstream of the dead switch.
- Your topology lives in a Visio file, exported to PNG, pinned in Teams. It was accurate the day it was drawn.
None of these systems share a device inventory. So when the poller fires "device down," the on-call tech opens four tabs and starts SSH-ing into the core to walk the MAC address table and CDP neighbors — reverse-engineering by hand what a live topology map would show on one screen.
Why the gap exists
Three structural reasons, and none of them are lazy admins:
- Discovery is batch, not event-driven. Most tools run scans nightly or weekly as a scheduled job. The network changes continuously — DHCP leases churn, new APs appear, someone plugs in a consumer router — but your data refreshes in discrete, instantly-stale snapshots.
- Topology is a report, not a data structure. In most platforms, the map is something you generate for management from the same stale inventory. It's not a live, typed record of "this MAC is on this port on this switch right now."
- The stack is siloed by design. Monitoring, RMM, helpdesk, and documentation each own a separate device list with no shared schema — the exact fragmentation problem Cloudflare is attacking with typed, structured extraction — so correlating "alert" + "affected users" + "ticket" is always manual work.
What it costs — in numbers a practitioner will recognize
Scenario 1: The anonymous dead access switch. An access switch power supply dies overnight. Your poller sends one email: "10.10.1.5 down." No topology, no context. The tech spends 20 minutes working out which closet that even is, 15 more identifying the 38 impacted users, then walks the floor. Total: 45–60 minutes before the actual fix — a 3-minute PSU swap or uplink reseat — even begins. MTTR of an hour for a five-minute hardware problem.
Scenario 2: The device nobody added. A marketing intern plugs in a consumer Wi-Fi router, or a security vendor installs IP cameras on the production VLAN. Nothing in the stack notices — the nightly scan might catch it Tuesday, if anyone reads the report. Then DHCP conflicts or a broadcast storm start, and the first "monitoring" signal is four annoyed users calling the helpdesk.
Scenario 3: SLA reporting theater. The IT manager needs to show leadership how the outage was handled. Monitoring has timestamps, the helpdesk has tickets, and neither has impact data. The "SLA report" becomes a manually stitched spreadsheet, and everyone quietly agrees to stop asking.
Multiply scenario 1 across 12 client networks and you have the MSP tax: unbillable triage hours, every month, on every onboarding where the client's "documentation" is a napkin.
How AlertMonitor Handles It: Live Topology, Typed Data, Full Context
AlertMonitor treats the network the way Clairic treats documents: as a stream of typed, continuously verified facts — not a periodic report.
Continuous discovery, not quarterly scans. Using SNMP, ARP, and active scanning, AlertMonitor continuously discovers and maps every device on the network: switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints. Each one appears as structured data — type, IP, MAC, vendor, location, link state — not a free-text blob in a spreadsheet.
The map is the live state. When a link drops, a switch goes offline, or a new device appears, the topology updates in real time and an alert fires instantly — with full network context. The alert doesn't say "10.10.1.5 down." It says "Access switch SW-FLOOR2 down, 38 devices and 1 printer impacted," and highlights exactly those nodes on the map.
One platform, one inventory. Because monitoring, RMM, helpdesk, patching, and topology share the same device inventory:
- A network alert auto-creates or links a helpdesk ticket, already tagged with impact scope.
- The tech remotes into any affected endpoint from the same console.
- Patch and agent status on impacted machines is visible without switching tools.
Before/after, one incident:
| Step | Fragmented stack | AlertMonitor |
|---|---|---|
| Detection | Poller email, no context | Instant alert with impact scope and map highlight |
| Scope | SSH into core, walk MAC/CDP tables (~35 min) | Read the map (seconds) |
| Respond | Walk the floor, ask users what's down | Remote actions from the same screen |
| Record | Manual notes after the fact | Auto-linked ticket with topology attached |
Teams running this workflow consistently report the same pattern: incident scoping collapses from 45–60 minutes to under five, and "unknown device on the network" stops being a post-incident surprise and becomes a one-minute alert.
Practical Steps: Reconcile Your Network Truth This Week
Before (or while) you move to live discovery, run this audit. It takes an afternoon and the results are usually humbling.
Step 1 — Diff your documented inventory against live reality. From a domain-joined machine (or better: pull the ARP table from your gateway/router, since a single host only sees its local segment):
# Compare live ARP entries against the documented inventory
$inventory = Import-Csv \"C:\\IT\
etwork-inventory.csv\" # columns: Hostname,IPAddress,MAC
$inventoryMacs = $inventory | ForEach-Object {
($_.MAC -replace '[:\\.\\-]', '').ToLower()
}
$live = Get-NetNeighbor -AddressFamily IPv4 |
Where-Object { $_.State -in 'Reachable','Stale' -and $_.IPAddress -notlike '169.254.*' }
$undocumented = foreach ($entry in $live) {
$mac = ($entry.LinkLayerAddress -replace '[:\\.\\-]', '').ToLower()
if ($mac -and $mac -ne '000000000000' -and $inventoryMacs -notcontains $mac) {
[PSCustomObject]@{
IPAddress = $entry.IPAddress
MAC = $entry.LinkLayerAddress
Interface = $entry.InterfaceAlias
}
}
}
$undocumented | Sort-Object IPAddress | Format-Table -AutoSize
Every row it returns is a device that exists on your network and in no documentation.
Step 2 — Sweep every subnet and build a dated baseline. From a Linux box or WSL host connected to each broadcast domain:
# Timestamped sweep so you can diff week over week
for subnet in 10.10.0.0/24 10.10.1.0/24 10.20.0.0/24 192.168.88.0/24; do
name=$(echo \"$subnet\" | awk -F. '{print $2\"-\"$3}')
sudo nmap -sn \"$subnet\" -oA \"discovery-$(date +%F)-$name\"
done
# Extract live hosts and diff against documented IPs
cat discovery-$(date +%F)-*.gnmap | grep 'Status: Up' | awk '{print $2}' | sort -u > live-hosts.txt
cut -d, -f2 network-inventory.csv | tail -n +2 | sort -u > documented-ips.txt
comm -23 live-hosts.txt documented-ips.txt > undocumented-devices.txt
cat undocumented-devices.txt
Note that nmap's -sn with MAC address output requires local network access — run it from a machine on the same broadcast domain as each VLAN, or you'll only get IP-level results across routers.
Step 3 — Verify your monitoring can actually see your infrastructure. A monitoring platform is only as good as its SNMP coverage. Find the blind spots before they find you:
# Check SNMP reachability on every network device; anything \"BLIND\" is invisible to your stack
COMMUNITY='your-snmp-v2c-community'
while read -r ip name; do
if snmpget -v2c -t1 -r1 -c \"$COMMUNITY\" \"$ip\" sysDescr.0 >/dev/null 2>&1; then
echo \"OK $name ($ip)\"
else
echo \"BLIND $name ($ip) <-- fix SNMP access before trusting any alert from it\"
fi
done < core-devices.txt
Step 4 — Replace the snapshot with a stream. In AlertMonitor: onboard the site, let continuous discovery map the environment, then configure alerts for new device appearances and link-state changes. Wire network alerts into the built-in helpdesk so every incident carries its topology context automatically. Then delete the Visio — or frame it, as a historical artifact.
The Takeaway
Cloudflare built Clairic because structured, typed, confidence-scored data beats free-text guessing — for extraction today, and for everything AI-assisted that comes next. Hold your own network to the same standard. A live topology map of typed, continuously verified device facts is the difference between an alert that says something is down and an answer that says what, who, and where.
Your users already know the network has changed. Your map should too.
Related Resources
AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.