Satellite SLA Explained

Service level agreements are the contractual backbone of any enterprise satellite deployment. They define — in measurable terms — what the service provider commits to deliver, what happens when those commitments are not met, and how performance is measured and reported. For terrestrial networks, SLAs are relatively straightforward: fiber and microwave links deliver predictable latency and availability, and the metrics are well understood by procurement teams. Satellite is different. The physics of the link, the shared nature of bandwidth, weather-dependent performance, and the operational complexity of remote terminal infrastructure all create an environment where SLA language can obscure as much as it clarifies.

For organizations deploying VSAT networks across remote sites — mining operations, maritime fleets, oil and gas platforms, rural enterprise branches — the SLA is often the single most important document governing the commercial relationship. Yet satellite SLAs are frequently misunderstood, poorly negotiated, or structured in ways that protect the provider more than the customer.

This article explains what satellite SLAs contain, what the key metrics mean from an engineering perspective, where the common pitfalls lie, and how enterprises should evaluate SLA terms before signing. For background on link performance metrics, see our guides on satellite link availability and how to evaluate a satellite internet provider.

---

What Is a Satellite SLA?

A satellite SLA is a formal agreement between a satellite service provider and its customer that specifies the performance levels, availability targets, support response times, and remedies that govern the service. It translates the technical capabilities of a satellite link into contractual obligations with measurable thresholds and defined consequences for non-compliance.

Unlike a marketing brochure or a sales proposal, the SLA is a binding document. It defines exactly what "99.5% availability" means (and, critically, what it excludes), how latency and bandwidth commitments are measured, what the provider's obligations are when something goes wrong, and what compensation the customer receives when targets are not met.

A well-structured satellite SLA typically contains these sections:

1. Service description — the specific satellite service being provided, including the circuit type (VSAT, SCPC, shared, dedicated), the coverage area, and the terminal equipment
2. Performance metrics — quantified targets for availability, latency, jitter, packet loss, and throughput (CIR/MIR)
3. Measurement methodology — how and where each metric is measured, what tools are used, and what the measurement interval is
4. Exclusions — conditions under which the SLA does not apply (force majeure, scheduled maintenance, customer-caused outages)
5. Support and escalation — response times by severity level, escalation procedures, and communication channels
6. Remedies and credits — the financial compensation or service credits when SLA targets are not met
7. Reporting — frequency and format of performance reports provided to the customer

The quality of an SLA is not determined by the headline numbers — it is determined by the definitions, exclusions, and measurement methodology that sit behind those numbers.

---

Core SLA Metrics in Satellite Services

Satellite SLAs typically define commitments across several performance dimensions. Understanding what each metric actually measures — and where the measurement boundaries lie — is essential for evaluating whether an SLA provides meaningful protection.

Availability

Availability is the most prominent SLA metric and the one most frequently quoted in sales conversations. It is expressed as a percentage representing the proportion of time the service is operational within a defined period, typically one calendar month.

For satellite services, 99.5% is a common availability target for standard VSAT services. Higher tiers (99.9%+) are typically reserved for dedicated SCPC circuits or services with gateway diversity and redundant earth station infrastructure.

The critical question is not what percentage is quoted, but how "availability" and "downtime" are defined. Is the service considered "available" if throughput drops below CIR? Is it "available" if latency exceeds the SLA threshold? These boundary definitions determine whether the availability number is meaningful or misleading.

Latency

Satellite latency SLAs define the maximum acceptable round-trip time (RTT) for the service. For geostationary (GEO) satellite links, the physics impose a minimum one-way propagation delay of approximately 120 ms (sub-satellite point) to 140 ms (beam edge), resulting in a minimum round-trip delay of approximately 480–560 ms through the satellite.

Typical GEO satellite SLA latency commitments range from 550 ms to 700 ms RTT, accounting for propagation delay plus processing, queuing, and encapsulation overhead at the hub and terminal. Some providers quote one-way delay, others quote RTT — always verify which is specified.

For medium earth orbit (MEO) and low earth orbit (LEO) constellations, latency SLAs reflect the shorter propagation paths but may include caveats around beam handover and inter-satellite routing that can introduce variability.

Jitter

Jitter measures the variation in packet arrival times and is particularly relevant for real-time applications like VoIP, video conferencing, and industrial control. Satellite SLAs that include jitter commitments typically specify a maximum jitter value (e.g., less than 15 ms or less than 30 ms) measured over a defined interval. For more detail on how jitter affects satellite services, see our guide on satellite jitter.

Packet Loss

Packet loss SLAs define the maximum acceptable percentage of packets that fail to reach their destination. For satellite links, packet loss is influenced by link conditions (rain fade, interference), congestion (particularly on shared services), and equipment faults. A typical satellite SLA packet loss target ranges from 0.1% to 1.0%, depending on the service tier. For the relationship between packet loss, BER, and FER in satellite systems, see BER, FER, and packet loss explained.

Throughput (CIR and MIR)

Throughput SLAs in satellite services are defined through two related but distinct metrics:

• CIR (Committed Information Rate): The minimum guaranteed bandwidth available to the customer at all times, regardless of network load. CIR represents the floor — the provider commits that the customer will always have at least this throughput.
• MIR (Maximum Information Rate): The peak bandwidth the customer can achieve when spare capacity is available. MIR is not guaranteed — it depends on how many other customers on the same beam or transponder are active at the time.

The ratio between CIR and MIR is directly related to the contention ratio of the service. A service with 2 Mbps CIR and 10 Mbps MIR has a 5:1 contention ratio. Understanding this ratio is essential for predicting real-world performance under load.

---

Availability Commitments Explained

Availability is the cornerstone metric of any satellite SLA, but the headline percentage is only meaningful in the context of how it is defined, measured, and what it excludes.

How Availability Is Calculated

The standard formula is:

Availability (%) = ((Total Minutes − Excluded Minutes − Downtime Minutes) / (Total Minutes − Excluded Minutes)) × 100

Where:

• Total Minutes = the total minutes in the measurement period (e.g., 43,200 for a 30-day month)
• Excluded Minutes = time excluded from the SLA calculation (scheduled maintenance, force majeure, customer-caused outages)
• Downtime Minutes = time the service was unavailable per the SLA's definition of an outage

The exclusion categories are where most of the complexity — and most of the provider protection — resides.

Common Exclusion Categories

1. Scheduled maintenance: Most SLAs allow the provider to perform planned maintenance without it counting against availability. The question is how much notice is required (24 hours? 7 days?) and whether there is a cap on scheduled maintenance hours per month.

2. Force majeure: Extreme weather, natural disasters, and other events beyond the provider's control are typically excluded. However, some providers define force majeure broadly enough to include severe rain fade events, which for Ka-band services in tropical regions can be a significant portion of the downtime.

3. Customer-caused outages: If the customer's terminal equipment, power supply, or local network causes the outage, the SLA typically does not apply. This is reasonable, but the burden of proof and the method for determining fault origin should be clearly defined.

4. Third-party events: Some SLAs exclude outages caused by the satellite operator (as opposed to the service provider who resells capacity), creating a gap where neither the satellite operator nor the service provider is liable for the downtime.

Measurement Point

Where availability is measured matters enormously. Common measurement points include:

• At the satellite gateway/hub: This measures availability of the hub infrastructure and satellite transponder, but does not account for last-mile issues at the remote terminal site
• At the remote terminal: This provides a more complete picture but requires monitoring infrastructure at each site
• End-to-end (hub to terminal): The most comprehensive approach, but also the most complex to implement and the most likely to capture weather-related events at the terminal site

Enterprises should insist on understanding where the measurement point is and what monitoring tools are used. An SLA that measures availability only at the hub effectively excludes all remote-site issues from coverage.

---

Performance Commitments Beyond Uptime

A service can be technically "available" while delivering performance so degraded that it is functionally unusable. Strong SLAs go beyond binary uptime measurement and include performance thresholds that define minimum acceptable quality during operating periods.

Bandwidth Guarantees Under Load

CIR guarantees are only meaningful if they are enforced under real-world congestion conditions. Key questions to evaluate:

• Is CIR measured at Layer 2 (including protocol overhead) or Layer 3 (application-level throughput)?
• Is CIR measured in a single direction (download-only) or bidirectionally?
• Does the CIR guarantee apply at peak hours, or only during defined measurement windows?
• What happens when throughput drops below CIR — is this considered an SLA breach, or is it only tracked after a sustained period (e.g., 15 minutes below threshold)?

Latency Under Load

Latency SLAs should specify whether the commitment applies to lightly loaded conditions (baseline latency) or under congestion (loaded latency). A satellite link that meets its latency SLA at 3 AM but consistently exceeds it during business hours provides little practical value. Well-structured SLAs define latency commitments at specified load levels or as percentile targets (e.g., 95th percentile latency below 650 ms).

Quality of Service Prioritization

Many enterprise satellite services include QoS (Quality of Service) tiers that prioritize different traffic types. If an SLA references QoS, it should specify:

• Which traffic classes are defined and how they are identified
• What performance commitments apply to each class
• Whether QoS is enforced only at the hub or also at the terminal
• How QoS interacts with CIR — does prioritized traffic count against CIR, or is it handled separately?

---

Operational and Support Terms

The operational terms in a satellite SLA define what happens when something goes wrong — how quickly the provider responds, what the escalation path is, and what the customer's role is in fault resolution.

Response Time vs Resolution Time

SLAs typically define two distinct time commitments:

• Response time: How quickly the provider acknowledges the fault and begins diagnostic activity. This is typically measured from when the customer raises a ticket (or when the provider's monitoring detects the fault, if proactive monitoring is included).
• Resolution time (MTTR): How quickly the actual fault is resolved and service is restored. This is the more important metric, but also the harder one for providers to commit to, especially for hardware failures at remote sites.

For remote satellite sites, MTTR is heavily influenced by logistics — spare parts availability, field technician access, and the remoteness of the site. A 4-hour resolution target is achievable for a site with on-site spares and trained local staff, but unrealistic for a mountaintop repeater site accessible only by helicopter.

Proactive Monitoring

Does the provider offer 24/7 network operations center (NOC) monitoring that detects outages before the customer reports them? Proactive monitoring with automated alerting significantly reduces the time between fault occurrence and fault response. If the SLA's response time clock starts only when the customer raises a ticket, the actual time-to-resolution is the detection delay plus the SLA's stated resolution time.

Spare Parts and Field Support

For services that include managed terminal equipment, the SLA should specify:

• Whether spare parts are stocked on-site, in-country, or at a regional depot
• What the logistics commitment is for replacement hardware delivery
• Whether the provider has field engineers who can be dispatched, or whether the customer is responsible for terminal-side troubleshooting and swap-out
• Whether remote terminal diagnostics and firmware updates are performed by the provider or left to the customer

Escalation Procedures

The SLA should define a clear escalation path — who to contact when standard support channels are unresponsive, what the escalation triggers are (e.g., MTTR exceeded, multiple sites affected), and whether the customer has access to engineering-level support or only Tier 1 help desk.

---

SLA Red Flags and Common Pitfalls

Satellite SLAs can contain provisions that appear standard but significantly reduce the provider's actual obligations. These are the most common pitfalls to watch for:

1. Availability Measured Only at the Hub

If the SLA measures availability at the satellite hub or gateway rather than at the remote terminal, the provider is only guaranteeing that the hub infrastructure is operational. Any issue between the hub and the customer's terminal — including satellite transponder faults, rain fade at the terminal site, and terminal equipment failures — may be excluded. This is the single most common SLA structure that favors the provider.

2. Overly Broad Force Majeure Clauses

Force majeure clauses that include "adverse weather conditions" or "atmospheric events" can exclude rain fade from the availability calculation. For Ka-band services in tropical or high-rainfall regions, rain fade can account for a significant portion of outage time. If the SLA excludes rain fade, the effective availability may be several percentage points lower than the stated figure.

3. Long Measurement Periods That Mask Outages

Some SLAs measure availability over a quarter or a year rather than monthly. A 99.5% annual availability allows for 1.83 days of downtime spread across the year — but if all of that downtime occurs in a single month (e.g., during monsoon season), the customer experiences 6 hours of downtime in one month while the annual SLA is still met.

4. No Distinction Between CIR and MIR in SLA

If the SLA references bandwidth without distinguishing between CIR and MIR, the provider can argue that the service is performing within specification even when throughput drops below what the customer expected. Ensure CIR is explicitly stated and that falling below CIR triggers the performance SLA.

5. Service Credits That Cap Below the Service Cost

Most SLAs cap service credits at 10–25% of the monthly recurring charge. This means that even a complete month-long outage might only result in a 25% refund. If the customer's business losses from downtime far exceed the service cost, the SLA credit provides minimal practical compensation. Credits are a remedy of last resort, not insurance.

6. Vague Definitions of "Outage"

Some SLAs define an outage only as a complete loss of signal, not as severe degradation. Under this definition, a link operating at 10% of CIR with 800 ms latency and 5% packet loss is still "available." Insist on performance-based availability definitions that count degraded performance as downtime when key metrics fall below acceptable thresholds.

7. Ticket-Based Downtime Tracking

If the SLA only counts downtime from the time a customer raises a trouble ticket until the provider closes the ticket, the actual outage duration may be significantly longer than the recorded downtime. Outages that occur outside business hours, on weekends, or that the customer does not immediately notice are not captured.

---

How Enterprises Should Evaluate Satellite SLAs

Evaluating a satellite SLA requires looking beyond the headline numbers and examining the structure, definitions, and practical enforceability of the agreement. Here is a systematic approach:

Step 1: Map SLA Metrics to Business Requirements

Before reviewing the SLA document, define what your applications actually need. A maritime fleet management system has different requirements from a remote-site video surveillance system or an enterprise backup WAN link. Document your minimum acceptable values for availability, latency, throughput, and support responsiveness, then evaluate the SLA against those requirements.

Step 2: Examine Every Exclusion

Read the exclusion clauses in detail. Calculate the practical impact of each exclusion on the effective availability. If rain fade is excluded and your terminal operates in a tropical region, request historical rain-fade data for your site's location and estimate how much downtime would be excluded from the SLA calculation.

Step 3: Verify Measurement Methodology

Ask the provider to explain exactly how each metric is measured. What monitoring tools are used? Where are the measurement probes? What is the polling interval? What is the minimum outage duration that is captured? Can you access the monitoring data directly, or do you rely solely on provider-generated reports?

Step 4: Evaluate the Remedies

Calculate the maximum service credit you could receive under the worst realistic scenario. If the credit is capped at 20% of monthly charges and a full-day outage costs your business $50,000 but the monthly service fee is $2,000, the SLA credit is $400 — less than 1% of your actual loss. For high-criticality deployments, consider negotiating enhanced remedies or carrying business interruption insurance.

Step 5: Assess Operational Readiness

Evaluate the provider's operational capabilities, not just their contractual commitments. Do they have a 24/7 NOC? Where are their field engineers based relative to your sites? What is their track record on MTTR for sites similar to yours? Request references from existing customers in similar geographies and industries.

Step 6: Benchmark Against Alternatives

Compare the SLA structure — not just the numbers — across multiple providers. A provider offering 99.5% availability with a narrow exclusion list and terminal-level measurement may provide better effective service than a provider offering 99.9% with broad exclusions and hub-only measurement. For a comprehensive evaluation framework, see our guide on how to evaluate satellite internet providers.

Step 7: Negotiate the Gap

SLAs are negotiable. Standard enterprise SLAs are starting points, not final offers. Key areas to negotiate include:

• Narrowing exclusion clauses (especially force majeure and weather)
• Adding performance-based availability (not just binary uptime)
• Increasing service credit caps
• Adding proactive monitoring and automated alerting
• Specifying terminal-level measurement points
• Including quarterly business reviews with raw performance data

For broader guidance on what to look for in an enterprise deployment, see our enterprise satellite internet guide.

---

SLA vs Real-World Engineering Reality

Even well-structured SLAs cannot fully capture the complexity of real-world satellite service delivery. Understanding the gap between SLA commitments and operational reality helps enterprises set realistic expectations and plan accordingly.

Weather and Link Margins

Satellite links are designed with a link margin — a buffer of signal strength above the minimum required for reliable demodulation. This margin determines the link's resilience to rain fade and other atmospheric attenuation. A link designed with 3 dB of rain margin in Ku-band will tolerate light to moderate rain, but heavy rainfall events will still cause outages. The SLA availability target is inherently tied to the link budget — a provider cannot deliver 99.99% availability on a link designed for 99.5% weather availability without investing in frequency diversity, site diversity, or higher-power equipment.

Shared Bandwidth Realities

On shared (contention-based) satellite services, the SLA's CIR is the guaranteed minimum, but real-world throughput fluctuates based on how many users are active on the same beam. During peak hours, throughput may hover near CIR even though the MIR is much higher. During off-peak hours, users may experience throughput close to MIR. The SLA cannot guarantee MIR — it only guarantees CIR. Enterprises that need consistent high throughput should evaluate dedicated (SCPC) services or negotiate for higher CIR ratios.

Terminal-Side Complexity

Many satellite service issues originate at the terminal site, not in the space segment or hub infrastructure. Power instability, antenna misalignment, cable degradation, local interference, and environmental factors (temperature extremes, humidity, wildlife damage) can all degrade performance or cause outages. These issues typically fall outside the provider's SLA if the provider does not manage the terminal equipment.

For organizations managing their own terminals, maintaining performance requires trained personnel, proper preventive maintenance schedules, and environmental monitoring. The SLA protects you from provider failures, not from site-level problems. For a practical guide to terminal deployment and maintenance, see our remote terminal commissioning guide.

Multi-Provider and Multi-Layer Dependencies

Enterprise satellite deployments often involve multiple providers — a satellite operator, a managed service provider, a local installer, and potentially a terrestrial backhaul provider for gateway connectivity. An SLA with the managed service provider may not cover faults originating at the satellite operator level. Understanding the liability chain and ensuring SLA coverage across the entire service delivery path is essential for comprehensive protection.

---

FAQ

What is a satellite SLA?

A satellite SLA (Service Level Agreement) is a contractual document between a satellite service provider and customer that defines measurable performance commitments including availability, latency, throughput, and support response times. It specifies how these metrics are measured, what conditions are excluded, and what remedies (typically service credits) apply when targets are not met.

What availability should I expect from a VSAT SLA?

Standard VSAT SLAs typically offer 99.5% monthly availability, which allows for approximately 3 hours 39 minutes of downtime per month. Premium services with dedicated bandwidth (SCPC) and redundant infrastructure may offer 99.9% or higher. The effective availability depends heavily on the exclusion clauses — a 99.5% SLA with narrow exclusions may deliver better real-world uptime than a 99.9% SLA with broad exclusions that remove weather events and maintenance windows.

What is the difference between CIR and MIR in a satellite SLA?

CIR (Committed Information Rate) is the guaranteed minimum bandwidth always available to the customer. MIR (Maximum Information Rate) is the peak bandwidth achievable when spare capacity exists on the shared transponder. Only CIR is contractually enforceable in an SLA. The ratio of MIR to CIR reflects the contention ratio of the service — a 5:1 ratio means five customers share the same pool of bandwidth above their individual CIR levels.

How are service credits calculated in satellite SLAs?

Service credits are typically calculated as a percentage of the monthly recurring charge (MRC) based on the severity and duration of the SLA breach. For example, each 0.1% below the availability target might generate a 5% credit, up to a cap (commonly 10–25% of MRC). Credits are usually applied against future invoices, not refunded as cash. Most SLAs require the customer to formally claim credits within a specified period (30–60 days) after the event.

Does rain fade count as downtime in a satellite SLA?

It depends on the SLA's exclusion clauses. Some SLAs explicitly exclude rain fade or "atmospheric events" from the availability calculation, particularly for Ka-band services where rain fade impact is more significant. Other SLAs include rain fade as downtime, reflecting the argument that weather resilience is a design choice the provider makes through link budget, frequency band selection, and gateway diversity. Always verify whether weather-related outages are included or excluded.

What is MTTR in a satellite SLA, and why is it important?

MTTR (Mean Time To Repair) is the average time between when a fault is confirmed and when service is restored. For satellite services, MTTR is critical because remote site locations often make physical repair difficult. A 4-hour MTTR is achievable for sites with local spares and trained staff, but can be unrealistic for remote or hard-to-access locations. Strong SLAs differentiate MTTR targets by severity level and may include separate commitments for remote vs accessible sites.

Should I negotiate my satellite SLA?

Yes. Standard SLAs are starting templates, and most providers expect enterprise customers to negotiate. Priority areas for negotiation include narrowing exclusion clauses (especially weather and force majeure), adding performance-based availability definitions (not just binary uptime), increasing service credit caps, specifying terminal-level measurement points, and including access to raw monitoring data. The leverage for negotiation increases with contract value and term length.

How do LEO satellite SLAs differ from GEO satellite SLAs?

LEO satellite SLAs reflect the lower latency of LEO orbits (typically 20–60 ms RTT vs 500–700 ms for GEO) but may include additional caveats around coverage continuity, beam handover latency, and constellation availability during the deployment phase. LEO services may also define availability differently due to the moving nature of the satellites — a terminal may experience brief gaps between satellite passes, which the SLA may or may not count as downtime. As LEO constellations mature, SLA structures are converging toward traditional telecom-style commitments, but the details still vary significantly between providers.

---

Key Takeaways

• Read the exclusions, not the headline number — a 99.5% availability SLA with narrow exclusions is stronger than a 99.9% SLA that excludes weather, maintenance, and terminal-side faults.

• Insist on performance-based availability — the service should be considered unavailable not just when the link is completely down, but when it operates below defined performance thresholds (CIR, latency, packet loss).

• Understand CIR vs MIR — only CIR is guaranteed. Build your capacity planning around CIR, not MIR, and evaluate the contention ratio to understand real-world throughput expectations.

• Verify the measurement point — an SLA measured at the hub protects the provider, not the customer. Push for terminal-level or end-to-end measurement where possible.

• Evaluate operational capability, not just contractual language — MTTR commitments are only as good as the provider's logistics, spare parts, and field support infrastructure for your specific sites.

• Service credits are remedies, not compensation — SLA credits rarely cover actual business losses from downtime. For critical services, negotiate enhanced credits and carry appropriate business insurance.

• Negotiate — SLAs are starting points. Enterprise customers with multi-site, multi-year contracts have significant leverage to negotiate narrower exclusions, higher credits, better monitoring, and performance-based commitments.

---

Related Articles

• Satellite Link Availability Explained — How link availability is calculated, the role of rain fade margins, and what availability figures mean in practice.
• How to Evaluate a Satellite Internet Provider — Comprehensive framework for assessing providers beyond marketing claims.
• Enterprise Satellite Internet Guide — End-to-end guide for planning and deploying enterprise satellite connectivity.
• Satellite Jitter Explained — Why jitter matters for real-time applications over satellite links.
• BER, FER, and Packet Loss Explained — Understanding error metrics and their impact on satellite link quality.
• Satellite Contention Ratio Explained — How shared bandwidth works and what contention ratios mean for throughput.
• Satellite Gateway Diversity — How redundant ground infrastructure improves availability and SLA compliance.