Service-level indicator
An SLI is the measured behavior, such as successful API responses, accepted submissions, webhook timeliness or final delivery outcomes for an explicitly defined population.
SMS service levels
Define measurable service levels before production
A useful SLA names the service boundary, indicator, calculation, target, measurement source, exclusions, reporting period, incident process and remedy. “Reliable messaging” is not measurable until those details are written down.
Service-level language
Separate indicators, objectives and commitments
Teams often use SLA as a label for every reliability number. Distinguishing the measurement from the internal target and the contractual commitment prevents dashboards and contracts from describing different services.
Service-level objective
An SLO is a target for an SLI over a period. It can guide operations without automatically creating a customer remedy.
Service-level agreement
An SLA is a written commitment that defines scope, target, measurement, exclusions, process and any remedy between the parties.
Do not combine unlike states: API availability, accepted message submissions, carrier handoff, final handset delivery and user verification completion are different indicators with different dependencies.
Measurement boundary
Define where responsibility starts and stops
Map the complete path from the customer application to the user's outcome, then state which segments the service level covers. A provider API can be available while a carrier rejects a sender, a handset is offline or the customer callback consumer is failing.
Customer request
Application authorization, input validation, connection, timeout and retry behavior before the request reaches the provider boundary.
API processing
Request receipt, authentication, validation and a documented response indicating rejection, acceptance or failure.
Route and carrier
Provider routing, sender registration, downstream handoff, carrier policy and network behavior.
Handset and user
Device reachability, number state, roaming, storage, filtering, user access and completion of the intended action.
Status return
Delivery report generation, mapping, webhook delivery, customer acknowledgment and application processing.
Indicators
Choose metrics that match the business workflow
No single percentage explains the health of an SMS service. Pair platform indicators with route, delivery and user outcomes, and define the eligible population for each calculation.
| Indicator | Example question | Definition to lock |
|---|---|---|
| API availability | Could valid requests reach the documented API and receive an eligible response? | Endpoints, status classes, timeout, regions, sampling and excluded requests. |
| Submission success | What share of valid requests were accepted for processing? | Validity rules, accepted status, duplicates, throttling and customer errors. |
| Submission latency | How long did eligible API processing take? | Start and end points, percentile, clock source, retries and timeout handling. |
| Final delivery rate | What share reached a defined final delivered state? | Countries, carriers, senders, status mapping, pending cutoff and denominator. |
| Delivery latency | How long from accepted request to final carrier or handset result? | Event timestamps, percentile, route, traffic class and missing receipts. |
| Webhook timeliness | How quickly were status events made available to the customer? | Event creation, first attempt, acknowledgment, retry and customer endpoint errors. |
| Support handling | How quickly are eligible cases acknowledged, updated or restored? | Severity, business hours, start time, pause rules, update cadence and resolution meaning. |
Calculation
Write the formula and data source into the agreement
A percentage cannot be reproduced without its numerator, denominator and eligibility rules. The monitoring record should retain enough message and request identifiers to reconcile the calculation without retaining unnecessary message content.
Availability example
Availability can be expressed as eligible successful service time divided by total eligible service time for the reporting period. The parties still need to define sampling, regions, partial degradation, dependency failures, planned maintenance and customer-caused events.
Event-success example
Event success can be expressed as eligible successful events divided by all eligible events. Define which status is successful, how duplicate attempts are treated, when pending becomes final and whether rejected customer input enters the denominator.
Percentiles matter: An average can hide a slow tail that harms OTP or time-sensitive notifications. If latency matters, define the percentile, traffic population, measurement clock and period.
Dependencies and exclusions
Make exclusions narrow, observable and testable
Exclusions should not be vague enough to remove every difficult incident from the measurement. Each exclusion should identify the dependency or customer action, the evidence used and the effect on the calculation.
Customer-controlled events
Invalid credentials, unauthorized senders, malformed requests, unavailable callback endpoints, unsafe retries, exceeded agreed throughput and customer network failure may sit outside a provider-controlled boundary when clearly documented.
Carrier and destination events
Number state, handset reachability, carrier filtering, sender registration, local regulation and downstream outages can affect delivery. The agreement should still state what routing, reporting and escalation behavior remains expected.
Maintenance
Define notice, permitted window, maximum duration, affected functions, emergency maintenance treatment and whether maintenance is excluded from each indicator.
Exceptional events
State the force-majeure or extraordinary-event treatment precisely. Require incident evidence and communication rather than assuming a broad label automatically removes measurement.
Incident operations
Connect severity to impact and communication
Severity should be based on observable production impact, not on who sends the most urgent message. The applicable support agreement must define formal priority, response target and escalation rights.
Critical impact
A material live workflow is unavailable, time-sensitive traffic cannot proceed and no reasonable workaround exists. Capture start time, scope, failure rate and affected destinations.
High degradation
Production continues with materially elevated errors, latency, delayed reports or loss of a significant route, sender or traffic subset.
Configuration blocker
A sender, route, webhook or launch step is blocked, while established production traffic remains available.
Question or request
Documentation, pricing, invoice, product behavior or planned implementation needs clarification with no current production impact.
Communication
Define what customers receive during and after an incident
Acknowledgment
State when the incident clock begins, what information confirms receipt and how an incorrect severity is corrected.
Progress updates
Define the channel, update cadence, affected functions, known scope, workaround and next expected update without making unsupported root-cause claims.
Closure and review
Define restoration, monitoring period, final communication, root-cause review eligibility and corrective-action follow-up.
Credits and remedies
Make the remedy process usable before an outage
If service credits or other remedies apply, the agreement should explain thresholds, calculation basis, caps, eligible fees, evidence, claim window, submission method, approval process and whether the remedy is exclusive.
Claim evidence
- Customer and account identifier
- Affected service and reporting period
- Request, message or case identifiers
- UTC event window and measured result
- Applicable commitment and requested remedy
- Evidence of any disputed exclusion
Terms to review
- Credit tiers and maximum amount
- Eligible recurring or usage fees
- Claim deadline and authorized submitter
- Relationship to termination rights
- Taxes, refunds and non-credit remedies
- Conflict with order-form amendments
Customer resilience
Design for controlled failure even with an SLA
A service credit does not restore a login or deliver a missed alert. The customer application should handle uncertainty, protect users and preserve evidence without amplifying an outage.
Bound retries
Use timeouts, backoff, jitter, idempotency and a maximum retry window. Do not retry permanent rejections or duplicate a send after an uncertain result without reconciliation.
Protect the user
Use clear status, safe resend behavior and alternative recovery paths appropriate to risk. Avoid revealing account existence or weakening authentication during a messaging delay.
Separate queues
Prevent a promotional burst or failing destination from consuming the capacity needed by verification and critical operational notifications.
Preserve observability
Correlate application, API, route, delivery and callback events with consistent identifiers and UTC clocks while excluding secrets and unnecessary content.
Review checklist
Resolve every field before relying on an SLA
Measurement
- Named service and eligible traffic
- SLI formula and authoritative data source
- Target, percentile and reporting period
- Timezone, rounding and missing-data rules
- Dependencies, maintenance and exclusions
Operations and remedy
- Severity and support clock
- Incident channel and update cadence
- Escalation and restoration meaning
- Credit threshold, calculation and cap
- Claim evidence, deadline and dispute path
Final verification: Confirm that the SLA references the same legal entity, account, product, route scope, effective date and order documents as the production purchase.
SLA questions
Does this page guarantee a TextPulse uptime percentage?
No. This page contains no numerical commitment. A guarantee exists only when the applicable written agreement defines the service, target, calculation, exclusions and remedy.
Is an accepted API request the same as a delivered SMS?
No. Acceptance, carrier handoff, final delivery report, handset receipt and user completion are different states. Measure each outcome required by the business workflow.
Should delivery rate be part of an SLA?
It can be an operational or contractual indicator if the eligible countries, carriers, senders, statuses, time window, dependencies and exclusions are precisely defined. A universal delivery promise would ignore factors outside one system boundary.
What is an error budget?
An error budget is the amount of unsuccessful behavior allowed while still meeting an SLO over its compliance period. It can guide release and risk decisions, but it is not automatically a customer credit.
Where should formal support response times be confirmed?
Confirm severity, support hours, clock start, pause rules, update cadence, escalation and response targets in the current support policy, SLA or service agreement that applies to the account.
Make reliability measurable before it becomes urgent
Agree on the boundary, indicator, data source, target, exclusions, incident process and remedy.