Tempo médio para a inocência: como provar que não é o WiFi

Speak in British English with a confident, authoritative, and conversational tone - like a senior network consultant briefing a client over a coffee. Measured pace, clear diction, occasional dry wit. Not a lecture. Not a sales pitch. Just straight talk from someone who has seen this problem a hundred times: Welcome to the Purple technical brief. I am going to talk to you today about something every network manager knows in their bones, even if they have never heard the formal term for it. Mean time to innocence. Or MTTI. [short pause] The time you spend proving it is not your fault. Here is the scenario. It is nine in the morning. Residents in a build-to-rent block start calling the front desk. The WiFi is broken. The property manager calls the managed WiFi provider. The managed WiFi provider calls the ISP. The ISP says check the router. The router team says check the access points. The access point vendor says check the client devices. And somewhere in the middle of all that, forty-five minutes have gone by, and nobody has actually fixed anything. That, right there, is mean time to innocence in action. [short pause] And it is costing you more than you think. Let me define it properly. Mean time to innocence is the average elapsed time between when a problem is detected and when any given team can demonstrate, with evidence, that their domain is not the root cause. It is not the same as mean time to identify, which is the organisation-wide metric for finding the actual root cause. MTTI is siloed. It is personal. It is the network team saying, here is the data, it is not us, now look elsewhere. The problem is that without the right tooling, that proof takes time. And every minute of MTTI is a minute added directly to your mean time to resolution, your MTTR. The two are inseparable. So why does the WiFi always get blamed first? [short pause] Three reasons. First, WiFi is visible. When something breaks, people look at the thing they can see, and the WiFi signal bars on their phone are the most visible indicator of connectivity. Second, WiFi is the last hop before the device, so it is the first thing that looks suspicious when a device cannot reach the internet. Third, and this is the uncomfortable one, WiFi teams often cannot prove innocence quickly because they lack the right telemetry. If you cannot show a clean bill of health for the wireless layer in under two minutes, you are going to spend the next hour defending yourself. Now, in a single-tenant enterprise environment, this is annoying. In a multi-tenant environment, it is genuinely damaging. Think about a hotel like Premier Inn, or a build-to-rent residential block, or a conference centre running back-to-back events. You have a property manager who does not own the network. You have residents or guests who do not understand the network. And you have a managed WiFi provider who is responsible for the wireless layer but not the ISP circuit, not the in-building cabling, and not the client devices. When something breaks, the property manager blames the WiFi provider because that is the contract they can point to. The resident blames the building because that is who they pay rent to. And the WiFi provider has to exonerate the network fast, or the relationship deteriorates. [short pause] MTTI is not just a technical metric in this context. It is a commercial one. So let us talk about the methodology that actually shortens it. There are five layers, and you need all five. Layer one: continuous synthetic checks. Before any ticket is raised, you should have automated probes running from the network itself, testing DNS resolution, HTTP reachability, latency to known endpoints, and authentication flows. Tools like Juniper Mist's Marvis, or the synthetic testing built into platforms like ThousandEyes, run these checks every few minutes. When an incident occurs, you can pull up a graph and show exactly when the WiFi layer last had a clean synthetic check, and whether it was clean or degraded at the time of the complaint. That alone cuts MTTI dramatically, because you either confirm the WiFi was healthy, or you confirm it was not, and you stop arguing about it. Layer two: hop-by-hop path visibility. This is where most teams fall down. You can prove the access point is healthy. You can prove the switch is healthy. But can you prove the path from the switch to the ISP handoff is healthy? In a multi-tenant building, there are often hops you do not own. The in-building distribution network, the landlord's core switch, the demarcation point to the ISP. You need path trace data that crosses those boundaries. Not just a ping to eight-eight-eight-eight. Actual traceroute-style visibility that shows you every hop, its latency, and whether it is dropping packets. When you can show that hops one through four are clean and hop five, which is the ISP's edge router, is showing forty percent packet loss, the conversation changes immediately. Layer three: flow data with on-demand packet capture. NetFlow and IPFIX give you a conversation-level view of what is talking to what on the network. When a resident says the streaming service is broken, flow data tells you whether traffic to that service's IP ranges is even leaving the network. If it is leaving the network clean and the problem is downstream, that is your evidence. If it is not leaving the network at all, you know where to look. On-demand packet capture, available on platforms like Cisco Meraki and HPE Aruba, lets you grab a targeted capture for a specific client or VLAN without touching the hardware. That is your forensic layer. You use it sparingly, but when you need it, it is definitive. Layer four: topology and dependency mapping. In a multi-tenant environment, you need a live map that shows which access points serve which tenants, which switches those APs connect to, which uplinks those switches use, and which ISP circuit serves each uplink. When an incident occurs, you can immediately identify the blast radius. Is this affecting one tenant or all tenants? One floor or the whole building? One VLAN or all VLANs? That scoping question, answered in thirty seconds from a topology map, tells you whether the problem is in the WiFi layer, the building network, or the WAN. It also tells you who else to loop in, and who you can immediately exclude. Layer five: event correlation. This is the one that ties everything together. Change logs, ISP maintenance alerts, device firmware updates, power events, and user complaints all need to sit on the same timeline. When you overlay a spike in client association failures with a firmware push that happened twelve minutes earlier, you have your root cause. When you overlay a latency spike with an ISP maintenance window that was not communicated to you, you have your evidence for the escalation. Event correlation is not glamorous, but it is the difference between a forty-five-minute blame game and a four-minute exoneration. Now, a word on the cultural dimension, because this is where a lot of teams get it wrong. The goal of reducing MTTI is not to win the blame game faster. It is to end the blame game entirely. [short pause] Shared evidence changes the dynamic. When the WiFi provider can send the property manager a link to a dashboard showing green across the wireless layer, amber on the in-building switch, and red on the ISP circuit, the conversation stops being adversarial. It becomes collaborative. The property manager calls the ISP. The ISP fixes the circuit. The residents get connectivity back. And the WiFi provider's contract is renewed because they were the ones who found the problem. That is the commercial case for investing in observability tooling. Not just faster troubleshooting, but better relationships with the people who pay you. Let me run through a couple of quick scenarios to make this concrete. Scenario one: a 350-room hotel. Guests at a Premier Inn-style property start reporting that the in-room WiFi is slow. The front desk logs a ticket with the managed WiFi provider. With synthetic checks running, the provider can see that DNS resolution times spiked from twelve milliseconds to four hundred milliseconds at seven forty-three in the morning. The WiFi layer is healthy. The path trace shows the latency is introduced at the third hop, which is the ISP's aggregation router. The provider sends the hotel manager a screenshot of the path trace with the degraded hop highlighted in red, alongside the synthetic check graph showing the WiFi layer was clean throughout. The ISP is called. The ISP confirms a routing issue on their side. Total time from complaint to exoneration of the WiFi layer: six minutes. MTTR for the full incident: twenty-two minutes, because the ISP fix took sixteen minutes. Without the observability tooling, that six-minute exoneration would have been forty minutes of back-and-forth, and the MTTR would have been over an hour. Scenario two: a retail chain. A national retailer with WiFi across two hundred stores notices that the point-of-sale terminals in one region are intermittently losing connectivity to the payment processor. The network team is immediately blamed. Flow data shows that traffic to the payment processor's IP range is leaving the store network cleanly. The problem is not the network. A packet capture on the payment processor VLAN shows TCP retransmissions spiking, which points to a server-side issue at the payment processor. The network team shares the flow data and the capture summary with the payment processor's support team. The payment processor identifies a misconfigured load balancer on their side. The network team's MTTI: eight minutes. The payment processor's fix time: thirty-five minutes. Without the flow data, the network team would have spent those thirty-five minutes reprovisioning VLANs and rebooting switches that were working perfectly. Right. Let me give you the rapid-fire version of the key questions I get asked on this topic. Is it the WiFi or the device? Run a synthetic check from the AP itself. If the AP can reach the internet cleanly and the device cannot, it is the device. If the AP cannot reach the internet, it is upstream of the device. Is it the WiFi or the ISP? Path trace to the internet. If the latency or loss is introduced at a hop outside your network boundary, it is the ISP. What is the difference between MTTI and mean time to identify? MTTI is your team's time to prove innocence. Mean time to identify is the organisation's time to find the actual culprit. MTTI is a subset of mean time to identify. How do I cut MTTI without buying new tools? Start with what you have. Most enterprise access point platforms, including Cisco Meraki, HPE Aruba, and Juniper Mist, have built-in synthetic testing and client diagnostics. Use them. Document your topology. Build a shared dashboard that the property manager or operations team can see. Transparency is the cheapest MTTI reduction tool available. To wrap up. Mean time to innocence is the hidden tax on every network incident. In multi-tenant environments, where accountability is fragmented across providers, landlords, and ISPs, it is the metric that determines whether you retain contracts or lose them. The methodology to reduce it is not complicated: synthetic checks, path visibility, flow data, topology mapping, and event correlation. The goal is not to win the blame game. It is to replace the blame game with shared evidence, so that every team can focus on fixing the problem rather than defending their patch. [short pause] Because every minute spent proving innocence is a minute added to the time your residents, guests, or shoppers spend without connectivity. And that is the number that actually matters. Thanks for listening. If you want to see how Purple's Multi-Tenant WiFi platform surfaces this kind of observability data across 80,000 live venues, head to purple dot ai.