Integration platform SLAs are commonly written around a monthly availability percentage for the platform, support response times by severity, and service credits if the target is missed. Check whether yours also covers your own workflows: delivery latency, success rate, restore time and update turnaround.
The question IT leaders ask is usually this: "What do integration uptime and update cadence commitments typically look like from platform vendors, and how do IT teams hold them accountable when things slip?" Both halves matter. A commitment you cannot measure cannot be enforced, and a measurement without a remedy changes nothing. This guide is for CTOs, engineering leads and IT directors who depend on a shared integration platform, or who are about to sign one. It does not rank vendors or quote their terms, because terms differ by contract and change; it gives you a way to read and write them. For the integration choices that come before the contract, see system integration approaches and the enterprise integration patterns decision guide. If you want a team to design and run integrations under your own standards, see our systems and API integration service.
Key takeaways
- A vendor's uptime figure covers the vendor's platform, measured at the vendor's boundary. It may not cover your flows, upstream outages or latency.
- Convert every percentage into minutes. 99.9% in a 30-day month is 43.2 minutes of allowed downtime.
- Ask for service-level indicators you can measure yourself: delivery latency, success rate, restore time and update turnaround.
- Monitor independently with canary flows and daily reconciliation, and keep timestamped evidence.
- Credits are commonly a partial remedy against fees, not compensation for business impact. Negotiate termination rights and exit help for chronic failure.
- Design so that a vendor outage delays data instead of losing it.
What do integration uptime commitments typically look like?
They are commonly a monthly availability percentage for the platform, with exclusions for scheduled maintenance and factors outside the vendor's control, a claims process, and service credits against future fees. The numbers sound close together but differ greatly in minutes. Always convert them.
Read the contract, not the marketing page, because definitions decide everything. The table shows what common availability figures allow; the arithmetic is exact.
| Availability | Allowed downtime per 30-day month | Allowed downtime per year |
|---|
| 99% | 7 hours 12 minutes | About 3.65 days |
| 99.5% | 3 hours 36 minutes | About 43.8 hours |
| 99.9% | 43.2 minutes | About 8.76 hours |
| 99.95% | 21.6 minutes | About 4.38 hours |
| 99.99% | About 4.3 minutes | About 52.6 minutes |
Ask how availability is measured (which endpoint, from where, how often), what counts as "down" (total outage or any degraded state), and whether the figure is per customer or averaged across all customers.
It may not cover your outcomes. A platform can be "up" while scheduled jobs start late, webhooks queue, a connector fails after an upstream change or one noisy tenant slows others. Ask for each of the items below to be covered or to be explicitly excluded.
| Item | Check whether the headline SLA covers it | What to ask |
|---|
| Platform console and API availability | Check | How is it measured and from where? |
| Scheduled flow starts on time | Check | Is there a start-delay commitment? |
| Webhook and event ingestion | Check | Is receipt, not only endpoint uptime, covered? |
| Delivery latency end to end | Check | Is a percentile target offered? |
| Connector bugs and upstream API changes | Check | Who fixes, and how fast? |
| Outage of a third-party system (your CRM, ERP) | Check | How are partial outages reported? |
| Scheduled maintenance | Check | How much notice, and what monthly limit? |
| Support response | Check | Response and restore targets by severity? |
What should a measurable integration SLA contain?
Use the vocabulary of service levels. A service-level indicator (SLI) is a measurement, a service-level objective (SLO) is the target for it, and a service-level agreement (SLA) is the contract with consequences. Define each indicator precisely enough that you and the vendor would calculate the same number.
| Indicator | Definition | How you measure it | Example target (illustrative) |
|---|
| Availability | Share of minutes the ingestion endpoint accepts requests | Synthetic checks every minute | 99.9% monthly |
| Delivery latency | Time from event received to delivered to the target | Timestamps on a test record, 95th percentile | Within 60 seconds |
| Run start delay | Time between scheduled and actual start | Job logs | Within 5 minutes |
| Flow success rate | Runs that finish without a platform-caused error | Run history, excluding customer-caused errors | 99.5% |
| Time to acknowledge and restore | Incident opened to first response and to service restored | Ticket timestamps | By severity |
| Notification time | Incident start to vendor notice | Status page and email timestamps | Within 15 minutes |
| Root-cause report | Written analysis after a major incident | Delivery date | Within a stated number of business days |
| Update turnaround | Time to support a new version of an upstream API | Release notes against the source's schedule | Before the old version is retired |
The targets above are illustrative examples of how to phrase terms, not market norms. Set yours from the business impact of delay on each flow.
What does "update cadence" mean, and how do you write it down?
Update cadence is how fast the vendor keeps its connectors current with the systems they connect to, and how it changes its own platform. Write it as commitments about notice and turnaround: advance warning of breaking changes, support for new upstream API versions before old ones retire, a published changelog and a staging environment.
Source systems change: API versions are retired, authentication methods change, fields are added. A platform that does not keep pace turns into a source of silent failures. Useful clauses:
- Notice period before the vendor makes a breaking change to its own APIs or connectors.
- Commitment to support a new upstream API version before the old one is retired, where the upstream provider publishes a retirement date.
- A changelog, release notes and a staging or sandbox environment where you can test changes before they reach production.
- Version pinning for connectors where the platform allows it.
- Treat roadmap statements as intentions. Only what is in the contract is a commitment.
How should real-time and webhook-driven sync be specified?
Define "real-time" as a latency percentile from change to delivery, state the delivery guarantee and ordering rules, and require a replay window. Webhooks are usually delivered at least once and can be missed, so also require a periodic reconciliation poll as a backstop.
When your engineering team needs fast propagation of CRM or ERP changes, the useful questions are not "which platform is best" but these:
- Does the platform receive source events directly (webhooks, change streams) or poll, and at what interval?
- What is the delivery latency at the 95th and 99th percentile, and how is it measured?
- How are duplicates, retries and ordering handled? See integrations that survive failures.
- How long does the platform retain and retry undelivered events, and can you replay them?
- What does the source system itself guarantee? The platform cannot be faster or more reliable than the events it receives.
- Are signatures on inbound webhooks verified?
It should say how the vendor isolates your account from other customers' load, whether the SLA is measured per account or averaged across all customers, and how you are told about throttling. Put each point in writing and test it with a heavy-load test account.
For the engineering controls in your own product, read noisy-neighbour isolation in multi-tenant SaaS. For the vendor, put these questions in writing:
| Question | Why it matters |
|---|
| Are rate limits and queues applied per account? | A shared queue lets another customer's burst delay your events |
| Is the SLA measured per account or across all customers? | An average can hide a bad month for you |
| Is a dedicated capacity option available for large bursts? | Gives a path if you outgrow shared limits |
| How are you told when you are being throttled? | Silent throttling looks like an outage |
| Is delivery latency reported per account? | Lets you verify the isolation yourself |
Test it as well: in staging, run a heavy load for one test account and watch delivery latency for another.
How do IT teams monitor a vendor independently?
Do not rely on the vendor's status page. Run synthetic canary flows that push a test record through each critical path every few minutes, track delivery latency and success in your own tools, reconcile counts daily and store timestamped evidence of every incident.
- Canary flows. A test record in a test tenant crosses the same path as production data and is verified at the far end.
- Heartbeat alerts. Alert when expected volume drops to zero during business hours.
- Independent clock. Use your own timestamps to compute downtime, and compare them with the vendor's reports.
- Reconciliation. A daily report of counts and totals by flow shows silent loss.
- Status feeds. Subscribe to the vendor's incident feed and map it to the flows you depend on.
- Evidence log. Request IDs, error messages and times, kept for the credit claim and the monthly review.
What happens when commitments slip: escalation, credits and remedies?
Follow a defined ladder: record evidence, open a ticket at the right severity, request a root-cause report, claim any credit within the contract window, review at a monthly service meeting, require a corrective action plan with dates, and escalate to executive sponsors. Chronic failure should trigger termination or exit rights.
| Step | Action | Owner |
|---|
| 1 | Capture evidence and open a ticket at the contract severity | Integration owner |
| 2 | Request status updates at the agreed interval | Incident lead |
| 3 | Receive root-cause report | Vendor service manager |
| 4 | Submit credit claim within the claim window | Finance or IT contract owner |
| 5 | Review the monthly scorecard | IT director and vendor |
| 6 | Agree a corrective action plan with dates | Vendor |
| 7 | Escalate to executive sponsors | CIO or CTO |
| 8 | Invoke contractual remedies, such as termination for repeated misses | Legal and procurement |
In general terms, service credits are a partial remedy: commonly a reduction in future fees that scales with the size of the miss, subject to claim windows and caps, and often the stated sole remedy. They do not make up for lost orders or customer impact. Negotiate what matters more: a right to terminate after repeated misses in a defined period, help exporting your flows and configuration, and the root-cause obligation. Have counsel review limits of liability and exclusions.
Worked example: reading an SLA against a real month
This example is illustrative; the numbers are invented.
An order-sync platform has a 99.9% monthly availability SLA, so 43.2 minutes of downtime is allowed in a 30-day month. In one month the vendor's status page shows two incidents of 18 and 20 minutes, a total of 38 minutes, which looks within target. Your canary flow, however, shows failed deliveries for 25 and 31 minutes, a total of 56 minutes, because the vendor counted only complete outages and your flow failed during a degraded state.
The gap is the point. Your evidence asks the vendor to explain the difference, and the definition of "down" becomes a contract question. Meanwhile your outbox queue held every order, and nothing was lost once the platform recovered. In the next renewal, you ask for the availability definition to include degraded delivery and for a latency target.
What should you check before signing?
Check ten clauses before you sign: how availability is defined, the exclusions, latency and success targets, support times, incident communication, credits, termination rights, exit help, change notice and data handling. The table lists what to look for in each clause, so you can compare vendors on the same terms.
| Clause | Check |
|---|
| Availability definition | Measured where, how, and what counts as down |
| Exclusions | Maintenance limits, third-party failures, force majeure |
| Latency and success targets | Offered at all, and measured how |
| Support | Response and restore targets by severity, hours of cover |
| Incident communication | Notice time, update interval, root-cause report |
| Credits | Bands, claim window, cap, sole-remedy language |
| Termination | Rights for repeated misses |
| Exit | Export of flows, mappings and logs; transition assistance |
| Change notice | Breaking-change notice, staging environment |
| Data | Location, sub-processors, retention, deletion on exit |
When is this the wrong approach?
Not every flow needs a negotiated SLA. A nightly report feed that can run twice tomorrow does not justify contract effort. A contract also does not replace architecture: if a ten-minute outage loses orders, fix the design with queues and replay. For integrations you run yourself, you need internal objectives and an on-call process, not a contract. And smaller vendors may not offer stronger terms; weigh that against their other strengths.
Glossary: SLA, a contractual service-level agreement; SLO, an internal target; SLI, the measured indicator; canary flow, a synthetic test record that proves a path works; noisy neighbour, one tenant's load degrading others on shared capacity.
How Timeline Digital approaches integration service levels
For integrations that need measurable service levels, Timeline Digital uses the Plan step to agree the monitoring, canary checks and reconciliation your integrations need, so you can measure any service level yourself. Timeline Digital was founded in 2013, is based in Islamabad and delivers remotely. A free pilot of 2 to 3 key modules lets you test the result before the final agreement, schedules are set from your requirements in the Plan step, long-term support under a service level agreement follows launch, and the code is handed over on full payment. See our enterprise system integrations page.