A network SLA checklist should connect every performance promise to a defined measurement boundary, a qualifying failure and a contractual remedy. For AI connectivity, compare endpoints, protocols, sampling, percentiles, exclusions and notice rules before treating a dashboard number as a commitment to your application’s performance.
Start with one question: does the number describe the service you are buying? Read the executed agreement and incorporated SLA alongside the dashboard. Compare what is measured, what is promised and what you must do when performance falls short.
What is a network SLA for AI workloads?
A network service-level agreement defines performance commitments for a specified connectivity service, how compliance is assessed and what follows a qualifying failure. For an AI workload, the first procurement task is to identify which part of the workflow that commitment actually covers.
Do not infer a guarantee of model responses from a network latency commitment. Model availability, request processing, response quality and network transport are different things. If the business requirement concerns an application outcome, ask for an application-level commitment and a test that measures that outcome.
For the broader connectivity decision, use the AI-grade fiber buyer guide alongside the contract review. Keep physical architecture, measured network performance and commercial remedies as separate evaluation tracks.
Percepture’s SLA Boundary-to-Remedy Test
Follow each promise through six questions. This is an editorial review method, not a provider certification or a substitute for interpreting the agreement.
- Endpoint: Where does the measurement begin and end?
- Protocol: What exchange is being timed or checked?
- Window: Which samples and reporting period determine the result?
- Failure: What event qualifies as noncompliance?
- Obligation: Which contracting party must act, and by when?
- Remedy: What can the customer claim, through which procedure?
If one link is missing, put the unresolved question into the procurement record before comparing headline numbers.
What exactly are the start and endpoint?
Ask the provider to describe both ends precisely enough that your engineering team could reproduce the test. A city name or cloud-provider name is not a complete measurement boundary.
Record the monitoring origin, destination address or service, network handoff, traffic direction and covered service identifier. Ask whether the probe originates inside the provider’s network, at your premises or from another monitoring location. Then identify which parts of your intended path sit outside that boundary.
Consider three distinct scopes:
- Provider-to-provider measurement: Ask which network segment is represented and whether either customer access leg is included.
- Customer handoff to remote endpoint: Identify the handoff, remote destination and treatment of intermediate third-party networks.
- Application transaction: Specify the request, authentication, expected response and completion condition, not just the destination host.
Also separate the monitoring location from your production location. A probe from one facility should not be treated as a measurement from a different office or data center without an explanation of the relationship.
When evaluating a public resource such as Stealth’s AI connectivity offering, record its stated measurement method separately from the obligations in the agreement you would sign. Do not carry a public-page figure into the contract comparison without matching its scope and terms.
How do ICMP, TCP and API status differ?
These checks answer different questions. Your network SLA checklist should preserve the test name rather than placing every result in a generic latency column.
Match the test to the claim
| Check | What to identify | What not to infer |
|---|---|---|
| ICMP echo round-trip time | The elapsed time between sending an echo request and receiving its corresponding echo reply, including the origin, destination and timeout. | That a model API completed a request or returned a useful answer. |
| TCP connection check | The destination port, connection-establishment timing and conditions counted as success. | That the application processed an authenticated transaction successfully. |
| HTTP or API check | The request, response criteria, timing boundary and treatment of errors or partial responses. | That a successful status alone establishes response quality or completion of the full user workflow. |
ICMP round-trip time is a request-and-reply measurement, not a one-way delay measurement and not model inference latency. For a TCP check, ask whether the timer covers connection establishment only. For an API check, distinguish connection time, time to first response and completion of the response.
For a streaming AI application, specify whether success means receiving an initial response, receiving the complete output or completing the downstream task. Put that definition next to the timing requirement so the two cannot drift apart during evaluation.
The guide to low-latency networking for AI is a related technical resource. In the SLA comparison itself, keep transport timing separate from application timing.
Read successful samples, median and p95 together
A percentile needs a defined dataset. The median, or p50, describes the middle of the ordered observations. The p95 describes the 95th-percentile boundary under the chosen calculation method. Neither number is complete without the population, period and treatment of failures.
Ask for the sampling interval, timeout, aggregation window, reporting period and percentile calculation method. Clarify whether the reported figure comes from raw observations or from previously aggregated values. A percentile of interval averages is not the same calculation as a percentile of all individual observations.
Keep failures visible
Use separate fields for successful measurements, failed attempts and missing observations. Ask how each affects latency reporting, availability calculations and breach eligibility. Do not prescribe one denominator for every provider; require each provider to disclose the denominator it uses.
Hypothetical example: A monitor schedules 100 probes. Eighty return measurements and 20 time out. A median calculated from the 80 successful responses describes those responses. It does not account for the 20 timeouts as completed requests. Ask for the failure count and its contractual treatment alongside the successful-response percentile.
Missing readings need their own explanation. Ask whether the monitor failed to run, the collection system lost data or the destination failed to respond. Do not accept an unexplained blank as evidence of either success or service failure.
Do not add component p95 figures
Adding a network p95 to an application p95 does not establish the p95 of the combined workflow. Those percentile values do not identify which delays occurred together on individual requests.
For a workflow requirement, request paired transaction measurements or an end-to-end test. Define the workload, timing boundaries and failure handling before using its result as a procurement threshold.
What counts as a qualifying breach?
Turn the breach clause into an operational question: given a specific incident, could procurement, network operations and the provider reach the same conclusion from the same records?
Your network SLA checklist should capture:
- Threshold: The exact performance or availability condition being assessed.
- Duration: Whether failure must persist continuously, accumulate over a period or affect a stated proportion of samples.
- Covered scope: The circuit, endpoint pair, location or service to which the condition applies.
- Exclusions: The events and circumstances removed from the calculation.
- Evidence: The monitoring record, incident ticket and timestamps used to establish what happened.
- Dispute procedure: How conflicting customer and provider measurements are reconciled.
Ask how planned maintenance, customer equipment, third-party dependencies and monitoring failures are treated. Record the actual clause rather than assuming that an exclusion is narrow or broad from its heading.
Then walk through a hypothetical incident with the provider. Specify when degradation begins, when monitoring detects it, when a ticket opens and when recovery occurs. Ask which timestamps control eligibility and duration. This is a contract walkthrough, not a claim that the service has been tested.
What remedies and notice rules actually apply?
Read the executed agreement, incorporated service terms and order-of-precedence clause together. Locate the party responsible for the obligation, not just the company operating a public dashboard.
Record the claim deadline, required submission channel, supporting evidence, escalation route and treatment of disputed claims. Distinguish opening a support ticket from submitting a remedy request. Ask whether either action satisfies the other under the agreement.
Do not budget for reimbursement of lost business unless the executed terms expressly provide the relevant right. Compare service-credit eligibility, credit calculation, caps, exclusions and any language making a remedy exclusive. Treat cancellation, termination and repeated-failure provisions as separate clauses to review, not as automatic consequences of an SLA breach.
Legal should review liability limitations, consequential-loss provisions, termination rights, governing law, document precedence and the enforceability of the proposed terms. Finance should review the economic effect of the remedy. Network operations should confirm that the required evidence can actually be retained and submitted on time.
For cost comparison, request the total contracted charges, including applicable installation, recurring, equipment, monitoring and resilience costs. Compare those charges separately from hypothetical credits. A possible future credit is not a reduction in the committed purchase price.
Printable provider comparison worksheet
Print this network SLA checklist or copy the table into your evaluation document. Complete each provider column with the term, document name, version and clause reference. Blank cells are spaces for your procurement team to complete.
| Evaluation field | Provider A | Provider B |
|---|---|---|
| Contracting entity and covered service | ||
| Controlling documents and precedence | ||
| Monitoring origin and destination | ||
| Protocol, timing boundary and success condition | ||
| Sampling, timeout and reporting window | ||
| Percentile method and failed-sample treatment | ||
| Breach threshold, duration and exclusions | ||
| Incident evidence and dispute procedure | ||
| Notice channel, deadline and escalation owner | ||
| Credit calculation, limits and other remedies | ||
| Physical route evidence, reviewed separately | ||
| Total charges and unresolved exceptions |
Mark a row comparable only after the definitions match. Where they differ, describe the difference instead of forcing both offers into one score.
Red flags to resolve before signing
A fast number with an unnamed path. Request the measurement boundary and covered service. Do not compare it with a customer-to-application result until the scopes are reconciled.
Successful-response latency without failure accounting. Request the unsuccessful and missing observations, their denominators and their treatment under the agreement.
An SLA offered as proof of route diversity. Route diversity concerns physical architecture, not simply a performance promise. Request appropriate route documentation and ask about shared conduits, building entrances and other common failure points. Review sensitive infrastructure information through an agreed secure process.
A remedy without a usable claim procedure. Assign the internal owner who will preserve evidence and submit a claim. Resolve notice deadlines and required channels before an incident, not during one.
A public promise without a matching contract clause. Ask where the commitment appears in the documents you would execute. Keep sales explanations and public measurements separate from the contractual comparison.
The buying decision is not which provider displays the smallest number. It is which offer covers the path your workload needs, measures it in a useful way and assigns an obligation your team can understand and administer. Close each unresolved worksheet row before signing, or record the specific risk the buying committee is choosing to accept.
About Bob Generale
Bob Generale is President of Percepture and the author of this guide.
