It’s 2:14 AM. A synthetic check just failed. What you do next (and how long it takes) depends almost entirely on whether your monitoring data lives in one place or five.
This final post in Season 2 covers three topics that bring the series together: the step-by-step workflow for cross-monitor incident response, the architecture requirements for teams operating at MSP scale, and the four-stage maturity model that maps where any monitoring program sits and what comes next.
Start Here: What the Videos Cover
▶ Video 34 — “Cross-Monitor Incident Response: From Alert to Root Cause”
▶ Video 35 — “Multi-Tenant Operations & White-Label Service Delivery”
▶ Video 36 — “The Synthetic Monitoring Maturity Model: A Buyer’s Framework”
The 10-Minute Incident Response Workflow
What follows is a five-step incident response sequence starting from a single synthetic alert. On a multi-source platform, this workflow runs in under 10 minutes. On a single-protocol tool, steps 3 through 5 require switching to different applications — if they’re possible at all.
Step 1: Multi-Probe Confirmation
A single probe failure doesn’t confirm a service issue. It might be a local network problem at the probe location, a transient routing event, or a brief hiccup that has already resolved. Multi-probe confirmation — checking whether the failure appears across probes in multiple regions — is the gate between “one probe reported something” and “this is a real incident.” If only one probe is failing, the investigation focuses on that probe location. If probes in three regions are failing, the service itself is the problem.
Step 2: Related Synthetic Checks
Once an incident is confirmed, the next step is protocol triage. Is DNS resolving for the affected target? Is TLS returning a valid certificate? Is TCP connectivity up? The pattern of which checks are passing and which are failing narrows the failure domain immediately. DNS and TCP failing while ICMP passes rules out a network connectivity issue and points at the protocol layer. TLS failing while TCP passes points at a certificate or handshake problem.
Step 3: Traceroute History
With a failure confirmed and the protocol layer narrowed, the next question is: did the network path change before the alert fired? On a platform with continuous traceroute storage, this is a data lookup. In this scenario, the traceroute history shows a path change at 2:11 AM — three minutes before the first synthetic failure. That timestamp is the lead: something happened to the routing at 2:11 that preceded the service impact.
Step 4: SNMP Interface Data
The traceroute history identified a specific upstream device in the changed path. SNMP interface data for that device shows which interface is experiencing problems. In this scenario: GigabitEthernet0/0/3 has 4,800 input errors in the last five minutes, correlating precisely with the path change timestamp. The interface is the source of the routing change.
Step 5: NetFlow Correlation
The final step confirms the impact mechanism. NetFlow data shows that traffic shifted from the primary link to a backup link at 2:11 AM — triggered by the interface error condition. The backup link is now saturated. TCP connections are failing because the backup link doesn’t have capacity for the diverted traffic. Root cause: interface errors on Gi0/0/3 triggered an automated failover to an undersized backup.
The full sequence — confirm, triage, trace, SNMP, flow — took 8 minutes on a multi-source platform. On a single-protocol synthetic tool, steps 3 through 5 require opening SNMP console, flow analyzer, and a separate traceroute tool. That sequence typically takes 40+ minutes, involves two escalation calls, and produces a Slack thread as a substitute for correlated data. The outcome is the same. The time to resolution is not.
Multi-Tenant Architecture: When One Team Becomes Fifty Customers
Most monitoring platforms were designed for a single organization’s use. The data model assumes one namespace, one set of alert destinations, one brand. For MSPs and platform teams managing multiple customers, that design creates problems at every layer.
Multi-tenant synthetic monitoring requires four things that aren’t optional:
Multi-Tenant Architecture: When One Team Becomes Fifty Customers
Most monitoring platforms were designed for a single organization’s use. The data model assumes one namespace, one set of alert destinations, one brand. For MSPs and platform teams managing multiple customers, that design creates problems at every layer.
Multi-tenant synthetic monitoring requires four things that aren’t optional:
| Requirement | What It Means | Why It's Architectural, Not Configurable |
|---|---|---|
| Data isolation | Customer A cannot see Customer B's data under any circumstances | Application-layer filtering can be misconfigured. Data scoping must be enforced at the platform level. |
| White-label branding | Per-tenant logos, colors, domains, and email identity | The end customer should never see the underlying platform's name. You're delivering a service, not reselling access. |
| Role-based access control | Admin, viewer, and auditor roles scoped per tenant | A customer's viewer role should see only their tenant's data. RBAC must be tenant-scoped, not platform-scoped. |
| Per-tenant alert routing | Each customer's alerts route to their own escalation chain | Alert routing defined at the platform level routes everything to the MSP. That's not service delivery — that's a liability. |
The operational test is onboarding at scale. Adding the first customer is a proof of concept. Adding the fiftieth customer — with its own monitors, its own alert policies, its own users — in under an hour is an operational capability. If tenant provisioning requires custom engineering for each new customer, the platform wasn’t designed for service delivery.
The Synthetic Monitoring Maturity Model
The four-stage maturity model defines what monitoring looks like at each level of capability — and, more importantly, what’s missing at each stage and what to add next. It’s not a prescription. It’s a map.
| Stage | What You Have | What's Missing |
|---|---|---|
| Crawl | Single-location ICMP/HTTP, manual thresholds, email alerts | Multi-location, additional protocols, ML detection, integrations |
| Walk | Multi-location, HTTPS + TLS expiry + DNS, basic dashboards, alert integrations | ML anomaly detection, SNMP, path visibility, auto-tuning |
| Run | Multi-protocol, ML anomaly detection, alert auto-tuning, SLA reporting | Multi-source inventory, P2P/PBD, three-pillar ML, traceroute intelligence |
| Fly | Full multi-source inventory, three-pillar ML, probe-to-probe, PBD, continuous traceroute, AI workloads, multi-tenant, cross-monitor correlation | — |
Most teams enter at Crawl and advance to Walk quickly — the jump from single-location to multi-location with basic protocol coverage is well-understood. The Walk-to-Run transition is where progress often stalls: ML detection requires data history, SNMP configuration takes time, and auto-tuning needs operational buy-in. The Run-to-Fly transition requires the architectural decision to unify data sources rather than add more point tools.
The 12-Point Evaluation Checklist
This checklist covers the criteria introduced across all 12 Season 2 videos. Each item maps to a capability area where full-stack platforms and point tools differ. Use it when evaluating a new platform or auditing your current one.
-
1
Multi-protocol coverage HTTPS, ICMP, DNS, TCP, TLS, WebSocket, MCP
-
2
Multi-source inventory Synthetic + SNMP + NetFlow + OTel + Kubernetes + GPU in one system
-
3
Per-interface SNMP breakout Vendor OID profiles, not just device-level aggregates
-
4
Probe-to-probe mesh testing Bidirectional testing of your own backbone
-
5
Path bandwidth discovery Hop-by-hop capacity estimates via VPS probing
-
6
Continuous traceroute storage Automated path change detection over time
-
7
Three-pillar ML Anomaly detection + change-point detection + drift tracking
-
8
Alert auto-tuning and flapping detection Dynamic thresholds, not static ones
-
9
Pull-model probe architecture Local buffering and automatic backfill
-
10
Multi-tenant operations Data isolation, white-label branding, and per-tenant RBAC
-
11
AI workload monitoring LLM endpoints, MCP server chains, GPU cluster health, semantic assertions
-
12
Cross-monitor correlation Pivot from synthetic alert to SNMP, flow, and path data without switching applications
These twelve criteria were chosen because they represent meaningful capability gaps — between platforms that tell you something is wrong and platforms that tell you what is wrong, where, why, and since when. The gap between those two answers is the gap between reactive operations and foresight.
About Parlon
Parlon is an infrastructure observability platform built for enterprise teams operating complex, hybrid environments. Parlon combines active synthetic validation, real-time telemetry normalization, and learning-based alerting into a single platform — shifting operations from firefighting to foresight. Learn more at parlon.io.