Skip to content
Illustration of a monthly calendar with a 99.9% uptime bar and a small red downtime slice beside a clock, for the TheWriter.id guide on explaining uptime SLA to customers.

FTTH Operators • Customer education

How to Explain Uptime SLA to Customers

By Junun Saleh · Updated · Built on Google SRE, AWS, Ofcom, ISPreview, Google Fiber and detikInet sources, each linked below

A business customer reads “99.9% uptime” in the contract, then loses the connection three times during one Monday of video calls. Support replies, truthfully, that the network is within its SLA. The customer hears “we do not care”. Both sides are right, because an uptime percentage and the continuity a customer feels are different measurements. This page gives sales, support and marketing teams the definitions, the downtime arithmetic and the wording to explain an uptime SLA clearly, including what is excluded and how compensation works.

Quick answer: Explain an uptime SLA in three steps. First, separate availability, the share of time the service works, from reliability, how often it fails and how fast it recovers: 99.9% allows 43.2 minutes of downtime in a 30-day month whether that is one outage or forty-three. Second, translate percentages into minutes: 99% is 7.2 hours a month, 99.9% is 43.2 minutes and 99.99% is 4.32 minutes (Google SRE book). Third, state how downtime is measured, what is excluded and how credits arrive, for example a 25% credit when monthly uptime falls below 99.9% in one business SLA, or 10.34 pounds a day for a UK home line not repaired within two working days.

In this page, a service level agreement (SLA) is a written service commitment. Uptime or availability is the share of a period in which the service works. Reliability describes how often failures happen and how quickly service is restored. MTBF is the mean time between failures and MTTR the mean time to repair. An exclusion is a type of downtime the SLA does not count. A service credit is compensation, usually on a future bill, when the target is missed. The ITU-T keeps a standard vocabulary for these terms in Recommendation E.800, Definitions of terms related to quality of service.

How do you explain availability vs reliability to customers?

Availability is how much of the time the service works. Reliability is how often it fails and how quickly it comes back. A percentage captures the first and hides the second. The AWS Well-Architected framework defines availability as the percentage of time a workload is available for use, meaning it performs its agreed function successfully when required, and gives the formula as available time divided by total time (AWS Well-Architected Reliability pillar). Nothing in that formula records how many separate interruptions made up the lost time. For the customer-facing side of that question, see is fiber internet reliable.

That is the gap customers fall into. Forty-three one-minute drops and one 43-minute outage leave a 30-day month at the same 99.9%, and they are not the same service.

Two months with the same 99.9% uptime but different outage patternsTwo timelines of a 30-day month. In month A a single block of downtime lasting 43 minutes appears. In month B forty-three short blocks of about one minute each flicker across the month. Both total 43 minutes, which is 99.9 percent uptime.Two months, both at 99.9% uptimeMonth A: one outageTotal downtime 43 minutes. Felt as one bad evening.Month B: forty-three one-minute dropsTotal downtime 43 minutes. Felt as video calls that keep dropping.Schematic, not to scale. 99.9% over a 30-day month allows 43.2 minutes of downtime (Google SRE book).The percentage is identical; the customer experience is not. That is the gap between availability and reliability.Two months with the same 99.9% uptime but different outage patternsTwo timelines of a 30-day month. In month A a single block of downtime lasting 43 minutes appears. In month B forty-three short blocks of about one minute each flicker across the month. Both total 43 minutes, which is 99.9 percent uptime.Both months: 99.9% uptimeMonth A: one outage43 minutes in total. One bad evening.Month B: 43 one-minute drops43 minutes in total. Calls that keep dropping.Schematic, not to scale. 99.9% over 30 daysallows 43.2 minutes (Google SRE book). Samepercentage, different experience: that is thegap between availability and reliability.

Figure 1: Availability counts minutes; reliability is about how often and how long. Two months can share one percentage and feel completely different (schematic).

Where reliability comes from: failures and repairs

Availability has two levers. How often things break is the mean time between failures (MTBF). How long repairs take is the mean time to repair (MTTR). AWS gives the estimate as MTBF divided by the sum of MTBF and MTTR, and its worked example, 150 days between failures and a one-hour repair, comes to about 99.97%. Run the same example with a four-hour repair and the result falls to 99.89%, which is about 9.7 hours of downtime a year against 2.4.

How repair time changes availability when failures stay the sameTwo bars show a stretch of 150 days between failures followed by a repair. With a four hour repair, availability is 99.89 percent and about 9.7 hours are lost a year. With a one hour repair, availability is 99.97 percent and about 2.4 hours are lost a year. The red repair segment is four times shorter in the second bar.Faster repair raises availability, with the same failuresAvailability = MTBF ÷ (MTBF + MTTR)MTBF: average time between failures. MTTR: average time to repair. Here MTBF is 150 days (3,600 hours).Repair takes 4 hoursMTBF: 150 days between failures99.89%9.7 h a yearRepair takes 1 hourMTBF: 150 days between failures99.97%2.4 h a yearSchematic, not to scale. Arithmetic with the formula in the AWS Well-Architected Reliability pillar.Red = time to repair. Cutting repair time is often the cheapest way to raise availability.How repair time changes availability when failures stay the sameTwo bars show a stretch of 150 days between failures followed by a repair. With a four hour repair, availability is 99.89 percent and about 9.7 hours are lost a year. With a one hour repair, availability is 99.97 percent and about 2.4 hours are lost a year. The red repair segment is four times shorter in the second bar.Faster repair, higher availabilityAvailability = MTBF ÷ (MTBF + MTTR)MTBF: average time between failures.MTTR: average time to repair.Here MTBF is 150 days (3,600 hours).Repair takes 4 hoursMTBF: 150 days99.89%9.7 h down a yearRepair takes 1 hourMTBF: 150 days99.97%2.4 h down a yearSchematic, not to scale. Formula from the AWSWell-Architected Reliability pillar. Red is repairtime; cutting it is often the cheapest fix.

Figure 2: Same failures, different repair time (arithmetic on the AWS formula). Availability depends on how long repairs take as well as how often things break.

For an FTTH operator this is useful because the two levers belong to different teams. Network design and fiber protection affect how often service fails. Field operations, spares, alarms and customer communication affect how long it takes to recover. Telling customers about both makes an SLA sound like a service, not a number.

One practical choice follows. Google measures large distributed services by request success rate, because part of such a service is nearly always serving traffic somewhere (Google SRE book: Embracing Risk). A single customer line has no such cover; when it is down, it is down. In our view time-based measurement is the natural fit for an access line, and it should be reported with outage counts and the longest outage.

One SLA sentence, written two ways (illustrative)

TypicalThe network is guaranteed 99.9% availability in accordance with the SLA.
Customer-ready99.9% means that in a 30-day month your service may be down for up to 43 minutes in total. The percentage does not say how many outages that is, so we also report how many outages you had and how long each one took to fix.

How do you translate 99%, 99.9% and 99.99% uptime into real downtime?

Convert every percentage into minutes per month and hours per year, and say which period the SLA measures. Customers cannot picture 99.9%. They can picture 43 minutes. The Google SRE availability table gives the standard conversions, and its note says it assumes no planned downtime.

43.2 minof downtime a 30-day month allows at 99.9% uptimeGoogle SRE book
8.76 hof downtime a year allows at 99.9% uptimeGoogle SRE book
52.6 minof downtime a year allows at 99.99% uptimeGoogle SRE book
10×less downtime allowed for each extra nine of uptimeOur arithmetic on the same table

Allowed downtime at three common uptime promises
Uptime Per year Per month Per day What to say
99% 3.65 days 7.2 hours 14.4 minutes About seven lost hours every month. Few fiber customers would call this high availability.
99.9% 8.76 hours 43.2 minutes 1.44 minutes Under 45 minutes a month. A common business SLA target.
99.99% 52.6 minutes 4.32 minutes 8.64 seconds A few minutes a month. Ten times stricter than 99.9%, and usually costs more to deliver.
Allowed monthly downtime at 99%, 99.9% and 99.99% uptimeA bar chart of the downtime each uptime promise allows in a 30-day month. 99 percent allows 7.2 hours. 99.9 percent allows 43.2 minutes. 99.99 percent allows 4.32 minutes. Each extra nine makes the bar ten times shorter.What each promise allows in a 30-day month99% uptimePer year: 3.65 days7.2 hours a month99.9% uptimePer year: 8.76 hours43.2 minutes a month99.99% uptimePer year: 52.6 minutes4.32 minutes a monthMaximum downtime if the whole allowance is used. Full track = 99% (7.2 hours). Each extra nine cuts it tenfold.Source: Google SRE book availability table (assumes no planned downtime).Allowed monthly downtime at 99%, 99.9% and 99.99% uptimeA bar chart of the downtime each uptime promise allows in a 30-day month. 99 percent allows 7.2 hours. 99.9 percent allows 43.2 minutes. 99.99 percent allows 4.32 minutes. Each extra nine makes the bar ten times shorter.Allowed downtime in 30 days99% uptimePer year: 3.65 days7.2 hours a month99.9% uptimePer year: 8.76 hours43.2 minutes a month99.99% uptimePer year: 52.6 minutes4.32 minutes a monthFull track = 99% (7.2 hours). Each extra ninecuts downtime tenfold. Source: Google SRE bookavailability table (assumes no planned downtime).

Figure 3: The three promises in real time (Google SRE availability table). Moving from 99% to 99.9% cuts allowed downtime from 7.2 hours to 43 minutes a month.

The table is arithmetic: the share of the period that may be lost. It is not a forecast. Two points change how you present it.

  • The period matters. Google Fiber’s business SLA measures monthly uptime. An annual 99.9% allows 8.76 hours, and nothing in the percentage stops those hours falling in one bad day. Say whether your SLA is monthly or annual.
  • Planned work may or may not count. The SRE table assumes none. AWS says some customers exclude scheduled maintenance from total time, and advises against it, because users will probably want the service then too. Whatever your contract does, state it.

Why the customer’s line is weaker than any one part

An end-to-end service depends on a chain: the drop and ONT, the OLT and aggregation, the core and upstream links. AWS notes that when each element is a hard dependency, their availabilities multiply. Three good parts at 99.9%, 99.99% and 99.95% give about 99.84%, which is roughly 14 hours of downtime a year, more than 99.9% alone. The values in Figure 4 are illustrative, not measured, but the arithmetic is general: a per-component figure can overstate what the customer receives.

Three network parts with good uptime combine into a lower end-to-end figureThree boxes in a chain: drop and ONT at 99.9 percent, OLT and aggregation at 99.99 percent, core and upstream at 99.95 percent. A pulse travels along the chain and the running total falls from 99.90 to 99.89 to 99.84 percent. The customer gets 99.84 percent, about 14 hours of downtime a year.Parts that are each good can add up to lessDrop + ONT99.9%running total99.90%OLT + aggregation99.99%running total99.89%Core + upstream99.95%running total99.84%Customer gets99.84%about14 hours a yearEach part alone allows 8.8 hours a year or less. Together the chain allows about 14 hours, more than 99.9% alone (8.76 hours).Illustrative values. If each part is a hard dependency, availabilities multiply (AWS Well-Architected).Arithmetic: 0.999 × 0.9999 × 0.9995 = 0.9984.Three network parts with good uptime combine into a lower end-to-end figureThree boxes in a chain: drop and ONT at 99.9 percent, OLT and aggregation at 99.99 percent, core and upstream at 99.95 percent. A pulse travels along the chain and the running total falls from 99.90 to 99.89 to 99.84 percent. The customer gets 99.84 percent, about 14 hours of downtime a year.Good parts, weaker wholeDrop + ONT99.9%running total99.90%OLT + aggregation99.99%running total99.89%Core + upstream99.95%running total99.84%Customer gets99.84%about14 hours a yearEach part alone allows 8.8 hours a year or less;the chain allows about 14. Illustrative values. Harddependencies multiply (AWS Well-Architected):0.999 × 0.9999 × 0.9995.

Figure 4: End-to-end availability is the product of its parts (illustrative values). A customer cares about the whole chain, so a per-component uptime figure can overstate what they receive.

Higher targets also cost more. AWS says tighter availability targets generally need more rigorous testing, automated recovery and operations, and recommends working out the true need before designing for it. That is a useful sentence to give a customer who asks for “five nines” on a residential-grade line.

Two uptime targets, written two ways (illustrative)

TypicalSLA uptime: 99.99%.
Customer-ready99.99% is about 4 minutes of downtime in a month, or 53 minutes across a year. It is ten times stricter than 99.9%, which allows 43 minutes a month. We measure it monthly, and we report the minutes each month.

How do you explain SLA accountability, exclusions and service credits?

Say what is measured, what is excluded, what the customer gets and how it arrives, in that order. A commitment is only as clear as its weakest line. Most SLA disputes start at the exclusions, because that is where the customer’s count of bad minutes and the contract’s count part ways.

£10.34 a dayfor UK landline or broadband not fixed within 2 working days of a fault report, from April 2026Ofcom, 8 April 2026
25%of the monthly charge credited when a business fiber SLA falls below 99.9% uptimeGoogle Fiber, May 2022
30 daysnormal window for a UK automatic compensation bill creditOfcom, updated July 2026
£63mpaid under the UK scheme in 2024 across about 1 million paymentsISPreview, April 2026

What is measured

Define downtime in one sentence. Google Fiber’s Premium SMB SLA defines monthly uptime as total minutes in the month minus downtime minutes, divided by total minutes, and counts downtime only when service is unusable through a total loss of signal (Google Fiber SLA). The consequence is worth saying aloud: a slow connection is not “down” under that definition. If your SLA counts only total loss of service, tell customers so before they find out.

What is excluded

Common exclusions, with what to tell the customer
Exclusion How the sources treat it What to say
Planned maintenance Excluded by Google Fiber with at least 72 hours’ notice “Work we announce 72 hours ahead does not count, and we say when it will happen.”
Customer equipment or actions Excluded by Google Fiber; Ofcom excludes faults inside the home and customer breach “If the fault is in your router or wiring, we show you where our line test ends.”
Events beyond the provider’s control Google Fiber excludes them, such as commercial power outages. Ofcom’s scheme generally still pays for weather, strikes and third-party damage unless an exclusion applies “Tell the customer which rule applies to them, in one sentence.”
Part months or suspended service Excluded by Google Fiber for months with less than a full subscription or suspended service “The target applies to full months of active service.”
The same month counted by the customer and by the SLA contractA timeline of a 30-day month with four events. A 20 minute outage and a 30 minute outage count toward the SLA. Planned work with notice and a fault in the customer router are excluded. The customer felt 215 minutes of problems, 99.50 percent uptime. The contract counts 50 minutes, 99.88 percent, which is still below a 99.9 percent target, so a credit is due.One month, counted two ways20 min outagePlanned work, notice givenCustomer router fault30 min outageCounts toward the SLAExcluded by the contractSchematic month of 43,200 minutes, not to scale.What the customer felt: 215 minutes down = 99.50% uptimeWhat the contract counts: 50 minutes down = 99.88% uptimeBelow 99.9% (43.2 minutes allowed), so a credit is due even after the exclusions.Illustrative month. Exclusions follow the types listed in Google Fiber’s Premium SMB SLA (May 2022): planned work with notice,customer equipment and events beyond its control.The same month counted by the customer and by the SLA contractA timeline of a 30-day month with four events. A 20 minute outage and a 30 minute outage count toward the SLA. Planned work with notice and a fault in the customer router are excluded. The customer felt 215 minutes of problems, 99.50 percent uptime. The contract counts 50 minutes, 99.88 percent, which is still below a 99.9 percent target, so a credit is due.One month, counted two ways20 minPlannedCustomer30 minCounts toward the SLAExcluded: planned work, customer equipmentSchematic month of 43,200 minutes.Customer felt: 215 min = 99.50%Contract counts: 50 min = 99.88%Below 99.9% (43.2 min allowed): credit due.Illustrative month. Exclusion types follow GoogleFiber’s Premium SMB SLA (May 2022).

Figure 5: Why the customer’s number and the contract’s number differ (illustrative month). Exclusions reduce the counted minutes; they do not always remove the credit.

Figure 5 shows why exclusions deserve their own paragraph. In this illustrative month a customer experiences 215 minutes of problems, which would be 99.50% uptime. The contract counts 50 minutes after removing planned work and the customer’s own router fault. That is 99.88%, still below 99.9%, so a credit is due. Exclusions narrow the count; they do not always erase the credit. Showing the arithmetic prevents an argument.

What the customer gets, and how it arrives

Two published designs show the range. Google Fiber’s SLA credits 25% of the monthly recurring charge when uptime falls below 99.9%, capped at that level per month, and applies it automatically to the bill for the second billing cycle after the month, with monthly uptime reports. Ofcom’s UK scheme pays 10.34 pounds for each day a fault stays unrepaired after two working days, paid automatically once the customer has reported the fault, usually as a bill credit within 30 calendar days; it only applies to participating providers, and, as ISPreview notes, the scheme is voluntary (Ofcom).

Two examples of how an outage becomes a creditTwo rows of four boxes: trigger, exclusions, credit and delivery. The Google Fiber business SLA triggers below 99.9 percent monthly uptime, excludes planned work, customer equipment and power cuts, gives 25 percent of the monthly charge and applies it automatically on the second bill after the month. The Ofcom UK residential scheme triggers when a fault is not fixed within two working days of being reported, excludes faults inside the home and customer breach, pays 10 pounds 34 per unrepaired day and credits the bill normally within 30 days. Highlights move across the columns.Two ways to write accountabilityTRIGGEREXCLUSIONSCREDITDELIVERYBusiness SLA: Google Fiber Premium SMB (May 2022)Uptime below 99.9%in a month; downtime istotal loss of signalPlanned work (72 hnotice), customerequipment, power cuts25% of the monthlycharge, cappedApplied automatically,on the second bill afterthe monthUK residential: Ofcom automatic compensation (July 2026)Fault not fixed within2 working days ofbeing reportedFault inside the home,customer breach, orcustomer blocks repair£10.34 for each dayunrepaired (April 2026)Bill credit, normallywithin 30 days ofrestorationExamples of structure, not Indonesian rules. Ofcom’s scheme covers participating UK providers and still counts events such asweather; the business SLA excludes events beyond its control. Check the actual contract before quoting either.Two examples of how an outage becomes a creditTwo rows of four boxes: trigger, exclusions, credit and delivery. The Google Fiber business SLA triggers below 99.9 percent monthly uptime, excludes planned work, customer equipment and power cuts, gives 25 percent of the monthly charge and applies it automatically on the second bill after the month. The Ofcom UK residential scheme triggers when a fault is not fixed within two working days of being reported, excludes faults inside the home and customer breach, pays 10 pounds 34 per unrepaired day and credits the bill normally within 30 days. Highlights move across the columns.Two ways to write accountabilityBusiness SLA: Google Fiber (May 2022)TRIGGERUptime below 99.9%in a month; downtime istotal loss of signalEXCLUSIONSPlanned work (72 hnotice), customerequipment, power cutsCREDIT25% of the monthlycharge, cappedDELIVERYApplied automatically,on the second bill afterthe monthUK residential: Ofcom (July 2026)TRIGGERFault not fixed within2 working days ofbeing reportedEXCLUSIONSFault inside the home,customer breach, orcustomer blocks repairCREDIT£10.34 for each dayunrepaired (April 2026)DELIVERYBill credit, normallywithin 30 days ofrestorationExamples of structure, not Indonesian rules. Ofcom’sscheme counts events beyond anyone’s control; thebusiness SLA excludes them. Check each contract.

Figure 6: Trigger, exclusions, credit and delivery in two real designs. Whatever your terms are, a customer should be able to read these four things in that order.

In Indonesia, the example we found is a pro-rata design after a large event. When the SMPCS 2 cable break disrupted South Papua and Central Papua from 16 August 2025, Telkomsel reported a bill discount for IndiHome and Telkomsel Halo customers matching the length of the service degradation, plus replacement of internet quota that expired during the outage (detikInet, 25 August 2025). We did not find a published national SLA figure for residential FTTH, so state your own terms instead of borrowing a number.

Network planners compare these terms before they take a sales call, and they check what is published. What Network Planners and CTOs Actually Want Before They Take a Sales Call makes that point for fiber vendors generally: publish sourced, checkable material first. An SLA explainer that states the measure, the exclusions and the credit does that.

A credit clause, written two ways (illustrative; use your own terms)

TypicalService credits are subject to the SLA terms, conditions and exclusions.
Customer-readyIf we are down for more than 43 minutes in a month, you get a 25% credit on that month’s fee, added to your bill automatically. Work we announce 72 hours ahead, faults in your own equipment and power cuts outside our network do not count. Every month we send you the minutes we counted and the minutes we excluded.

What should an SLA explanation include before you publish it?

It should answer the customer’s next question before they ask it, and name its sources. Use this list to review a contract summary, a sales page, a support script or a monthly service report.

  • Does it give the uptime target and the period it is measured over, monthly or annual?
  • Does it convert the percentage into minutes a month and hours a year?
  • Does it say that the percentage does not limit how many outages there are?
  • Does it define downtime, including whether a slow connection counts?
  • Does it list the exclusions, each with its condition, such as notice for planned work?
  • Does it show one worked example of counted and excluded minutes?
  • Does it state the credit, whether the customer must claim, and when it arrives?
  • Does every number carry a date and a source, and is there a review date?
  • Who writes it, and which network and legal owners check it before it goes live?

Uptime SLA: frequently asked questions

What is an uptime SLA?

An uptime SLA is a written commitment to keep a service available for a stated share of time, usually a percentage per month. A complete one also says how downtime is measured, what is excluded, and what the customer receives, often a bill credit, if the target is missed.

What does 99.9% uptime mean in real time?

In a 30-day month, 99.9% uptime allows about 43.2 minutes of downtime. Over a year it allows about 8.76 hours. The figure says nothing about whether that time comes as one outage or many short ones, so state the measurement period and also report outage counts.

How much downtime does 99.99% uptime allow?

About 4.32 minutes in a 30-day month, or about 52.6 minutes in a year, according to the Google SRE availability table. That is roughly ten times stricter than 99.9%. Each extra nine cuts the allowed downtime tenfold.

What is the difference between availability and reliability?

Availability is the share of time a service works. Reliability is how often it fails and how quickly it recovers. A line can reach 99.9% availability with one long outage or many short drops, and customers experience those very differently.

Does 99.9% uptime mean there will be no outages?

No. It is a budget of allowed downtime, not a promise of continuity. At 99.9% a service can still fail several times a month and stay within its SLA, as long as the total downtime stays under about 43 minutes in a 30-day month.

How is SLA uptime calculated?

Most SLAs divide the minutes the service was up by the total minutes in the period. Google Fiber’s business SLA defines monthly uptime as total minutes minus downtime minutes, divided by total minutes. Check what counts as downtime and which minutes are excluded.

What is usually excluded from SLA uptime?

Common exclusions are planned maintenance with notice, faults in the customer’s own equipment, customer actions, and events outside the provider’s control. Google Fiber’s business SLA lists all of these, including commercial power outages. Ofcom’s UK scheme excludes faults inside the home and customer breach.

What is a service credit, and is it paid in cash?

A service credit is compensation for missed targets, usually applied to a future bill. In the sources reviewed, Google Fiber applies a 25% credit to the bill and Ofcom’s UK scheme pays a bill credit, normally within 30 days. Check whether your contract allows cash or only credit.

Do FTTH customers get compensation for outages?

It depends on the provider, contract and country. UK landline and broadband customers of participating providers get 10.34 pounds a day for faults not fixed within two working days. After a 2025 cable break, IndiHome gave a bill discount pro-rated to the length of the service disruption.

Sources

  1. Google SRE book: Availability table
  2. Google SRE book: Chapter 3, Embracing Risk
  3. AWS Well-Architected Framework: Reliability pillar, Availability
  4. ITU-T Recommendation E.800 (09/2008): Definitions of terms related to quality of service
  5. Ofcom: Automatic compensation, what you need to know (updated 20 July 2026)
  6. Ofcom: Quicker complaints resolution and more money in your pocket when things go wrong (8 April 2026)
  7. ISPreview: Ofcom raise UK consumer compensation payments for broadband ISP woes (April 2026)
  8. Google Fiber: Premium SMB Service Level Agreement (last modified 10 May 2022)
  9. detikInet: Kabel laut putus di Papua, Telkomsel dan IndiHome beri kompensasi ke pelanggan (25 August 2025)

Figures 1 to 6, the conversions, the checklist and the scripts are our illustrations and arithmetic, not published standards. Downtime conversions follow the Google SRE table (365-day year, 30-day month, no planned downtime). The 99.89% and 99.97% availability figures apply the AWS MTBF formula to a 150-day MTBF with 4-hour and 1-hour repairs, and the 99.84% chain figure multiplies three illustrative availabilities as hard dependencies. The Google Fiber SLA is a US business agreement last modified in May 2022 and may have changed; Ofcom’s compensation scheme is voluntary, covers residential landline and broadband customers of participating UK providers, and is used here as an example of structure, not as an Indonesian rule. The scheme’s coverage and payout figures come from ISPreview’s report. The ITU-T page is cited for the existence and title of Recommendation E.800; we did not quote its definitions. The Papua compensation is one event reported by detikInet and not a standing residential SLA. We found no published national SLA figure for residential FTTH in Indonesia.