A service level agreement is a commitment from an ISP to a customer about the quality of service they will receive, expressed in measurable terms with defined consequences for non-delivery. For residential ISPs, SLAs are rarely explicit: the service terms define the product but do not typically commit to specific availability percentages. For corporate CIR clients, SLAs are commercially essential: enterprises purchasing dedicated internet access make internal commitments based on your availability guarantees, and they will hold you to those commitments.
Designing SLAs correctly means committing to targets you can actually measure, that your infrastructure can actually achieve, with reporting that proves delivery rather than asserting it.
The SLA Components That Matter
Availability is the primary metric: the percentage of time during the measurement period that the service is operational within defined parameters. A 99.9% monthly availability target allows approximately 43 minutes of downtime per month. A 99.5% target allows approximately 3.6 hours. A 99% target allows approximately 7.2 hours. Choose your target based on honest assessment of your infrastructure's demonstrated reliability, not based on what competitors advertise.
Downtime definition matters as much as the percentage target. Scheduled maintenance windows are typically excluded from SLA downtime calculations, but the conditions for excluding them (advance notice period, maximum duration, frequency limit) must be explicitly defined. Partial service degradation, where the circuit is up but throughput is significantly below the contracted rate, may or may not be counted as downtime depending on how the SLA is drafted.
MTTR (Mean Time to Restore) is the second critical metric for corporate clients: how long will it take to restore service after a failure is reported. A 4-hour MTTR commitment means your escalation process must be designed to get a resolution within that window for any failure your operations team is responsible for, including escalation to upstream providers for problems beyond your direct control.
Latency and throughput targets are included in SLAs for CIR clients who are sensitive to jitter and packet loss, such as those running VoIP or video conferencing over the circuit. If you commit to latency targets, you need measurement infrastructure that can demonstrate compliance.
Measurement Methodology
An SLA is only as credible as its measurement. Claiming 99.9% availability based on informal operations records is not the same as demonstrating it through continuous monitoring with timestamped records.
The measurement methodology should specify: what is being monitored (the circuit endpoint, the subscriber gateway, or a specific service reachable through the circuit), how frequently (continuous polling at 1-5 minute intervals is standard), what constitutes a confirmed outage versus a transient blip (typically three to five consecutive failed polls), and how the data is stored and made available for reporting.
For corporate clients, consider giving them read access to the monitoring data for their specific circuit, either through your NMS's client portal feature or through a simple dashboard. Clients who can see their own circuit's monitoring data are less likely to dispute SLA calculations because they have the same data you do.
For residential ISPs without explicit SLAs, the same measurement infrastructure serves the internal purpose of knowing when you are experiencing degraded service before subscribers call to tell you.
Exclusions and Force Majeure
Define what is excluded from SLA calculations clearly and conservatively. Common exclusions: scheduled maintenance with defined advance notice period, events caused by the customer's equipment or actions, events caused by force majeure (natural disasters, civil unrest, power grid failure), and events caused by your upstream providers rather than your own infrastructure.
The upstream provider exclusion is where Pakistani ISPs need to be careful. If PTCL's international link goes down and your corporate client loses internet connectivity, that is your transit provider's failure rather than yours. But from the client's perspective, they contracted with you and the service is down. How this is handled in the SLA, through a pass-through clause that applies your upstream's SLA terms to the client, through a maximum exclusion period after which you remain liable regardless of cause, or through a network diversity requirement that provides redundancy against a single upstream failure, determines your liability in the most common failure scenarios.
Reporting
Monthly SLA reports for corporate clients should include: total service availability as a percentage for the month, any SLA events (downtime periods) with start time, end time, duration, cause, and resolution, any SLA credits due if availability fell below the committed target, and any scheduled maintenance windows that occurred during the period.
The report format should be consistent month to month so clients can track trends over time. Producing this report manually from NOC logs is feasible for a small number of corporate clients but becomes unsustainable as the CIR client base grows. Monitoring platforms with reporting features or a simple database query against your monitoring data are the practical approaches at scale.
For the monitoring infrastructure that generates the measurement data SLA reporting depends on, NOC Enablement & Monitoring covers the monitoring stack and reporting capability. For operators who want AI-assisted triage to reduce MTTR by getting alerts to the right engineer faster, NOC Intelligence reduces the human decision time between alert and action. For BCP commitments that underpin SLA recovery targets, Business Continuity Planning ensures the RTO targets embedded in SLAs are supported by actual tested recovery procedures.