When you resell an IoT platform under your own brand, the customer signs a service level agreement with you and only you. Your logo is on the dashboards, your name is on the invoice, and your phone rings when data stops flowing at 2 a.m. But you do not run the infrastructure, and that single fact creates the rule every clause in your SLA must obey: you cannot promise your customer more than your platform promises you.
Every commitment you write down is either backed by an upstream commitment or absorbed by you as unpriced risk. Most reseller SLAs fail because they were copied from templates written for companies that own their servers. Yours has to be built the other way around, starting from the document your vendor gives you.
The pass-through problem
Put the upstream SLA on the desk before you write a word of your own. If your platform commits to 99.9 percent uptime and you promise a customer 99.95, you have personally underwritten the difference: roughly 21 minutes of exposure every month with no infrastructure to fix and no upstream credit arriving when it fails.
Taking that gap on deliberately, priced into your fee, can be a legitimate commercial decision, and how you price the managed service is where that decision gets settled. Taking it on because nobody did the subtraction is how resellers end up funding service credits out of margin.
This is also why the vendor’s own SLA belongs on your platform selection checklist. TagoIO publishes its SLA at tago.io/sla and holds ISO 27001 certification, which gives a reseller an audited baseline to build against instead of a verbal assurance. If you are still choosing what to build on, the platforms integrators actually resell are the ones that publish their numbers.
Define uptime before you promise it
An uptime percentage without a definition is decoration. Three parameters give it meaning.
The measurement window comes first. 99.9 percent measured monthly allows about 43 minutes of downtime per month, while the same figure measured annually lets one brutal eight-hour outage disappear into eleven quiet months. Monthly is the honest window.
Second, what counts as down: a full outage only, or degraded service too? If the API answers in 30 seconds instead of 300 milliseconds, your customer experiences an outage whether or not your definition admits it.
Third, who measures and how it gets reported. A commitment the customer cannot verify breeds disputes, so name the monitoring source and commit to reporting incidents rather than waiting to be asked. Independent detection is also what lets you handle platform downtime as a managed service provider instead of learning about it from your own customer.
Data durability is not availability
These two get merged constantly and they are different promises with different stakes. Availability is whether the service responds right now. Durability is whether the data survives.
A platform can be down for an hour and lose nothing, and your customer gets an apology and a credit. Lost data is a different category of failure, often unrecoverable and sometimes a compliance breach.
Your SLA should carry separate language for each: an availability percentage with the definitions above, and a durability clause covering retention period, backup frequency, and what happens to data buffered during an outage. Ask your vendor the buffering question directly, because ingestion behavior during downtime is where durability quietly becomes availability’s problem.
Support tiers: commit to response, target resolution
Response time is how fast a qualified person engages. You control that through staffing, so commit to it firmly. Resolution time depends on where the fault sits, and when it sits in the platform, the fix happens in infrastructure you do not operate. Keep resolution as a stated target.
Tie both to severity. A Severity 1 incident, service down for all users, might carry a one-hour response around the clock and a four-hour restoration target. Severity 2, degraded but running, gets a four-business-hour response. Severity 3 covers questions and minor defects at one business day.
Set numbers your team can hit during a bad week, because a commitment missed monthly costs more trust than a commitment never made. Writing the limits down is also what makes support survivable as you grow past ten customers.
Maintenance windows and exit terms
Planned maintenance announced in advance sits outside the uptime calculation, and your announced windows must sit inside your vendor’s windows, so upstream maintenance never counts against you downstream. Commit to 72 hours of notice or more.
Exit terms are the clauses buyers remember. State that the customer can export their data in a documented, machine-readable format during the contract and at termination, name the timeline, and name the cost, ideally zero. On a platform with full APIs this clause costs almost nothing to honor, and it wins deals against competitors whose silence on exit says everything. Ignoring exit costs until the exit is one of the most expensive mistakes integrators make, and the same question sits at the center of vendor lock-in.
Clause patterns you can adapt
These are language patterns to hand your lawyer, not legal advice. A few shapes that work:
“Monthly Uptime Percentage means the total minutes in the calendar month, minus minutes of Downtime, divided by total minutes in the month. Scheduled Maintenance announced at least 72 hours in advance is excluded from Downtime.”
“Severity 1 incidents receive a response from a qualified engineer within one hour of report, 24 hours a day, seven days a week. Restoration targets are objectives, not guarantees.”
“Customer data remains the property of Customer. Within 30 days of termination, Provider will make all Customer data available for export in a documented, machine-readable format at no additional charge.”
“Service credits are calculated as a percentage of the monthly fee, capped at 100 percent of one month’s fee, and constitute the sole remedy for availability failures.”
Build it back-to-back
The method is mechanical. Lay the upstream SLA and your draft side by side and, for every downstream clause, write the name of the upstream clause that backs it or the margin that prices it. Anything backed by neither is a donation to your customer.
Revisit the pairing annually, because your vendor’s terms, your staffing, and your fleet size all move. This is also the document that changes when you shift from one-time projects to recurring services, since a subscription is a promise that renews every month.
The gap between what you receive and what you promise never disappears. A good SLA shrinks it, prices it, and puts your name only on what you control. Start from a published baseline: TagoIO’s SLA is at tago.io/sla. Book a demo or start free.
