A 99.9% badge makes comparison look simple, but the number has little meaning without a boundary. One AI agent request may cross a trigger, queue, runtime, model provider, retrieval system, customer tool, and response channel. Depending on the contract, only the runtime and API may be covered. Buyers should test the promise against the path their production agents actually use.
Begin With the Contractual Promise
Product pages and procurement documents often use reliability terms interchangeably. Separate the metric from its target and from the contractual consequence of missing it. Google's public SRE definitions of SLI, SLO, and SLA use the same separation.
If a document says “99.9% uptime” but does not define the measured service, denominator, observation source, exclusions, and remedy, it is not yet a usable buying criterion. NIST's cloud service metrics guidance emphasizes reproducible metric definitions; ENISA likewise tells cloud buyers to establish when a service counts as available and how security service levels will be monitored.
AI Agent Platform SLA Checklist
Use this table for the first contract pass. A “pass” means the answer is written into the binding agreement or an incorporated schedule, not only stated in a sales call.
| # | Verify | A contract-ready answer | Red flag |
|---|---|---|---|
| 1 | Covered services | Names runtime, API, trigger intake, connectors, queues, state, logs, control plane, and result delivery separately. | “The platform” with no component list or environment boundary. |
| 2 | Availability formula | Defines valid requests, success and failure, response threshold, partial outage, and the denominator. | A percentage with no testable definition of downtime. |
| 3 | Measurement | States the window, aggregation scope, monitoring source, time zone, and dispute evidence. | A status-page percentage assumed to equal the contractual calculation. |
| 4 | Dependencies | Allocates responsibility for model providers, tools, data stores, connectors, networks, and customer code. | Third parties excluded without a fallback, attribution, or escalation path. |
| 5 | Maintenance and exclusions | Caps scheduled windows, specifies notice, and limits customer, quota, force-majeure, and security-event exclusions. | Broad exclusions that can remove the incidents the buyer cares about. |
| 6 | Incident and support clocks | Separates detection, acknowledgment, customer notice, update cadence, response, restoration, and post-incident review. | A fast “response” target presented as a resolution promise. |
| 7 | Recovery and durability | Sets RTO and RPO by data class, plus backup cadence, retention, isolation, and restore-test evidence. | “Regular backups” without numeric recovery commitments. |
| 8 | Security and operational evidence | Provides scoped reports, certificates, audit rights, exportable logs, retention, and control ownership. | A badge with no entity, service, period, exceptions, or report access. |
| 9 | Remedies | Defines credit tiers, eligible fees, cap, claim deadline, evidence burden, escalation, and repeat-failure rights. | Credits described without the claim procedure or exclusive-remedy language. |
| 10 | Change and exit | Covers adverse-change notice, export formats, retrieval period, transition help, deletion proof, and exit cost. | The provider can change terms while the customer has no tested export path. |
Map the runtime, connectors, model providers, recovery targets, support window, and evidence your agents need. Connic can document custom Enterprise terms where the public SLA is not enough.
Review your requirementsMap the Agent's Critical Path Before Negotiating Uptime
An agent run can be accepted while the business task still fails. The model endpoint may time out, a tool may reject credentials, a connector may not deliver the result, or the model may return an unusable answer. Put the production path on one page and assign an owner and contract to every layer.
| Layer | Failure to test | Evidence to request |
|---|---|---|
| Trigger and intake | Dropped, duplicated, delayed, or rejected event | Receipt ID, timestamp, retry history, dead-letter state |
| Queue and runtime | Run never starts, stalls, or loses durable state | Run status, queue delay, trace, retry and timeout reason |
| Model | Provider error, rate limit, latency, or poor output | Provider request ID, model/version, token and latency trace |
| Tools and data | Permission, network, schema, retrieval, or customer-code error | Tool call, identity, parameters, response, approval record |
| Result delivery | Business system never receives the final outcome | Delivery attempt, acknowledgment, retry, terminal state |
Keep output quality out of the uptime definition. Accuracy, policy compliance, and task completion need use-case tests and production evaluation. See how to build an agent test suite and trace production agent runs. The SLA should make the infrastructure measurable; it cannot guarantee that a probabilistic model gives the right answer to every prompt.
Turn “Nines” Into an Outage Budget
Convert the headline target into minutes, then repeat the calculation using the actual contractual denominator. The figures below assume a 30-day month and no excluded minutes. Maintenance, minimum event duration, low-traffic thresholds, or third-party exclusions can make the effective protection materially smaller.
| Monthly target | Downtime budget | Before exclusions |
|---|---|---|
| 99.9% | 43 minutes 12 seconds | 0.1% of 43,200 minutes |
| 99.95% | 21 minutes 36 seconds | 0.05% of 43,200 minutes |
| 99.99% | 4 minutes 19 seconds | 0.01% of 43,200 minutes |
Ask whether availability is measured per customer, Project, region, component, or the provider's entire fleet. A fleet-wide average can hide one customer's outage; a per-component calculation can create multiple narrow guarantees that never measure the complete production path. Also establish whether the provider's telemetry is final or whether customer logs can rebut it.
Separate Incident Communication From Support Response
A one-hour response target usually commits the provider to acknowledging the ticket. It does not promise restoration in one hour. Record each clock separately and say when it starts: provider detection, customer report, or severity confirmation.
A useful escalation schedule also names the supported channel, who can declare a P1, the executive escalation point, and what the customer must provide. Ask whether the post-incident report covers timeline, contributing factors, impact, corrective actions, and recurrence prevention—not merely a status-page summary.
Put Recovery Targets and Proof in Writing
Uptime describes whether a service is available. It does not say how much state can be lost or how quickly a damaged service can be rebuilt. NIST's contingency planning guide treats the recovery time objective (RTO) and recovery point objective (RPO) as separate planning inputs.
Contract for ongoing access to operational evidence. Buyers should be able to export timestamps, run states, failures, model and configuration versions, tool calls, identities, approvals, and delivery attempts. Define log retention and redaction so the records last long enough for SLA claims and investigations without becoming an uncontrolled store of personal or secret data. ENISA's cloud contract monitoring guide recommends ongoing security feedback between periodic assessments.
Read the Credit Clause From the Claim Deadline Backward
Start with the claim mechanics: eligible fees, automatic or requested credits, percentage tiers, monthly cap, filing deadline, required logs, provider decision process, and expiry. Then check whether credits are the exclusive remedy. For a critical workload, counsel may also seek escalation or termination rights after repeated material failures rather than a larger credit alone.
Before signing, enumerate the agent code, configuration, secrets references, run history, traces, evaluation data, files, and retrieval content that can be exported. State the formats, API availability, retrieval window, transition help, deletion confirmation, and cost. The EU Commission's voluntary cloud switching clauses offer a current reference for switching, termination, security, and business-continuity language. Applicability of the EU Data Act still needs a service- and contract-specific legal assessment.
Legal Review: Examine the Full Contract Stack
| Document | What it should answer | It does not replace |
|---|---|---|
| SLA | Availability, incidents, support, recovery, measurement, and remedies | Privacy terms or customer continuity planning |
| DPA | Roles, instructions, security, subprocessors, breach help, audits, return, and deletion | The controller's lawful basis, notices, DPIA, and configuration duties |
| Security schedule | Technical controls, responsibility split, vulnerability handling, and assurance evidence | A scoped report, certificate, test result, or contractual recovery target |
| Subprocessor schedule | Entity, purpose, location, transfer path, change notice, and objection process | Review of customer-selected model, tool, or data providers |
| Order form and addenda | Custom uptime, support, RTO/RPO, liability, regulated workloads, and precedence | Testing that the operational design can meet those requirements |
Under GDPR Articles 28, 32, and 33, a buyer acting as controller must use processors that provide sufficient guarantees, document the processor relationship, assess security appropriate to risk, and address breach notification and assistance. Those duties cover confidentiality, integrity, availability, resilience, and timely restoration, but a platform's uptime percentage does not establish GDPR compliance.
Sector rules can demand more. For financial entities in scope, DORA Article 30 requires detailed ICT contract terms and adds precise service targets, incident assistance, contingency testing, audit access, and transition requirements for services supporting critical or important functions. NIS2 requires covered essential and important entities to manage incident, continuity, and direct-supplier risk through national implementing law. Review the official DORA text and NIS2 text with counsel rather than treating either as a universal AI platform rule.
How Connic's Public Terms Answer the Checklist
Connic's public documents let buyers complete much of the first review before an Enterprise sales conversation. The Service Level Agreement is dated July 30, 2026 and applies to Pro and Enterprise. Because the covered boundary, calculation, exclusions, credits, incident communication, and support clocks are visible, the Enterprise review can focus on any custom terms the workload needs.
| Checklist area | Published Connic baseline | Enterprise review point |
|---|---|---|
| Availability and scope | 99.9% per monthly billing cycle for agent execution, connectors, and REST API | Negotiate a higher target or additional covered surfaces where the business impact requires it. |
| Exclusions | Dashboard, development/preview, non-GA features, customer code, quotas, and third-party providers are outside the stated boundary. | Map model, BYOK, tool, and delivery fallbacks rather than assuming end-to-end coverage. |
| Incidents | 15-minute acknowledgment after detection, updates at least every 30 minutes, and a significant-outage report within five business days | Add customer-specific notification, restoration, escalation, and report-content terms if needed. |
| Support | P1 initial response in one hour; standard support clocks run 09:00–18:00 UTC on weekdays. | Specify 24×7 coverage and resolution or restoration objectives where required. |
| Recovery | The security page describes backups, redundancy, and regularly tested disaster recovery, but publishes no numeric RTO or RPO. | Set numeric objectives by state and data class and request recent restore-test evidence. |
| Credits | 10%, 25%, or 50% tiers; 50% monthly cap; claim within 30 days; credits are the sole SLA remedy. | Review eligible fees, repeat-failure escalation, and any negotiated termination rights. |
| Privacy and assurance | Public DPA, security practices, subprocessor list, audit process, and customer responsibility split | Request current reports and certificates, then verify entity, scope, period, exceptions, and service coverage. |
For an Enterprise review, bring a one-page list of the business-critical agent paths. Add the downtime budget, data-loss budget, support window, required evidence, and legal constraints for each path. The gaps between those requirements and the public baseline become the negotiation brief for the order form.
Share your critical agent paths, support hours, recovery targets, data obligations, and evidence needs. We will show where the public baseline fits and where custom Enterprise terms make sense.
Discuss your SLA