Every platform goes down eventually. Yours, your competitor’s, the hyperscaler under both of you: uptime is a percentage, not a promise of immortality, and a managed service provider who has not planned for the bad hour is betting the customer relationship on luck. The reseller position has an uncomfortable structure: when the platform fails, the customer calls you, not the vendor, because your logo is on the portal. But downtime handled well is not just damage limitation. MSPs that run a disciplined incident routine consistently come out of outages with more customer trust than they went in with, because the outage is the one moment the customer actually watches you work.
The routine below runs from before the incident to after it.
Before: know about it first, and know what “down” means
The unforgivable version of downtime is learning about it from a customer. Independent monitoring is the fix: an external check that exercises the real customer path, data in, API read, portal load, from outside the platform’s own infrastructure, plus a subscription to the vendor’s status page. TagoIO publishes its status at status.tago.io, and your monitoring should reference it automatically. The detection layer is also where the platform’s own analytics and health checks help you: fleet-level anomaly detection distinguishes “one site’s gateway lost power” from “ingestion stopped everywhere at once,” which are different incidents with different first moves.
Just as important is knowing what down means for your service specifically. An IoT stack fails in layers, sensors, connectivity, network server, platform, integrations, and your SLA’s scope clauses should already map who owns each layer. We covered how those documents change as you move to recurring services. Most “platform down” tickets are actually connectivity or hardware, and diagnosing the layer in the first ten minutes decides whether you communicate an outage or dispatch a site visit.
During: buffer where you can, communicate like you mean it
Two properties of IoT soften most platform outages, and your architecture should exploit both.
First, LoRaWAN network servers and most gateways buffer or retry uplinks, and devices keep measuring regardless, so a storage-layer outage usually means delayed data, not lost data. Knowing your stack’s actual buffering behavior, how long, at which layer, turns “is my data gone?” into a question you can answer precisely, and it is a question every customer asks.
Second, edge components keep local logic alive: where a use case genuinely cannot tolerate cloud gaps, an on-premises layer like TagoCore keeps local alerting and control running through a cloud incident, and that belongs in the design conversation for critical deployments, not in the apology afterward.
Then the part MSPs underestimate: communication cadence beats communication content. The routine that works is fixed and boring. Acknowledge to all affected customers within the first 30 minutes, before they open tickets, with what you know, what still works, and when the next update comes. Update on the stated schedule even when the update is “no change.” Never speculate on a fix time you do not control; relay the vendor’s estimate, labeled as such. Customers forgive downtime with startling consistency. They do not forgive silence.
During: what your SLA was for
The incident is where the paperwork earns its keep. Severity levels route the response, scope clauses keep you from apologizing for a carrier outage, and the back-to-back alignment between your customer SLA and your vendor SLA decides whether a bad month costs you margin or just credits that offset upstream. If an incident reveals a gap between the two documents, that is a contract fix, not just an operational lesson.
After: the routine that converts outages into renewals
When service restores, three steps close the loop properly.
Verify data integrity before declaring victory: check the buffered uplinks arrived, backfill gaps where the stack allows it, and tell customers what the data record actually shows for the outage window. Send a short post-incident note within 48 hours, what happened, what the impact was, what changes, in plain language, unprompted. Apply service credits proactively if the SLA triggers them; the invoice arriving already-corrected is worth more goodwill than the credit itself.
Then feed the incident back into the machine: does monitoring need a new check, does a critical customer need an edge component, does the support tier pricing reflect who actually consumed the incident hours?
The quiet conclusion
An MSP cannot promise a platform never fails. What an MSP can promise, and get paid for, is that failure is detected in minutes, diagnosed to the right layer, communicated on a schedule, buffered where the architecture allows, and closed with an honest accounting. That is a product, and it is one of the strongest differentiators a managed service can sell, precisely because most competitors improvise it.
It also starts with a vendor whose baseline you can trust: published status, published SLA, audited operations. TagoIO gives resellers that foundation. Book a demo or start free.
