Service Level Agreement: Downtime Minutes, Cloud Credits, OJK

A service level agreement (SLA) is the contract schedule that fixes what a provider will deliver and how its performance is measured. For a bank's digital channel, read every SLA figure in minutes: 99.9% over a 30-day month allows 43.2 minutes of outage, or 8.76 hours a year. Indonesian banks must assess their IT vendors against that agreement under POJK 11/POJK.03/2022 Article 30(5)(c), so the SLA is the official yardstick for vendor performance reviews, not a formality stapled to the back of the contract.

That definition follows the Indonesian government's own wording. Directorate General of Treasury Regulation PER-8/PB/2020 (31 March 2020), Article 1 point 5, describes an SLA as an agreement that identifies the services and performance agreed between the parties. This piece is for the Head of Digital or CIO who signs channel-vendor contracts, and for the compliance team that has to show OJK the SLA schedule carries the contract items OJK asks for.

How much downtime a service level agreement allows, in minutes

One formula covers it: allowed downtime = (1 − A) × minutes in the measurement period. A 30-day month has 43,200 minutes; a 365-day year has 525,600. The last column adds one worked assumption: a 4-hour weekly maintenance window that the contract excludes from measurement. Averaged out, that's 30/7 × 240 = 1,028.6 minutes per 30-day month, and the availability target then applies only to the 42,171 minutes that remain.

That last column is the one nobody prints. When we measured Google Indonesia's results for "sla adalah" on 16 October 2026, its AI Overview offered a bare "99.9%" and no arithmetic at all. Run the numbers and a channel sold as "99.99%" can be dark for about 1,033 minutes, roughly 17.2 hours, in a month while its SLA report stays green. At "99.9%" the figure is 17.8 hours. In a calendar month the weekly window lands 4 or 5 times, so the excluded time runs from 960 to 1,200 minutes.

Our view: four nines without a cap on maintenance hours is a marketing number, not a promise. The gap between 99.9% and 99.99% is 38.9 minutes a month. An uncapped maintenance window can be about 26 times that.

A 28-day February only matters when the SLA is written in minutes rather than a percentage: 99.9% in February is 40.3 minutes, not 43.2. When the contract states a percentage, what decides the outcome is the definition of the measurement period, so get that definition in writing.

Three things the 99.9% figure doesn't tell you

Where availability is measured

Cloud providers measure at the edge of their own infrastructure. The Google Cloud Compute Engine SLA defines downtime as a loss of external connectivity or persistent disk access, and interruptions shorter than one minute don't count. The Amazon Compute SLA excludes internet problems beyond the EC2 demarcation point. Your customers never experience infrastructure. They experience a login that fails in the mobile banking app. So a bank channel SLA should name a measurement point that can be audited: a synthetic probe running from mobile and fixed-broadband networks inside Indonesia, from Jakarta and at least one other city, walking the journey from login to balance check, with a stated interval and a rule for how many consecutive failed probes count as downtime.

What is excluded

The Microsoft Azure SLA general terms (October 2026 edition) say it plainly: downtime does not include Scheduled Downtime, meaning network, hardware or service maintenance announced at least five days in advance. The table above shows how wide that gap is. The clauses to ask for: a monthly cap on maintenance hours, windows placed outside peak transaction hours (for a retail bank, payday around the 25th and the days before Lebaran are the obvious ones), and any maintenance beyond the cap counted as downtime.

Response is not resolution

Availability, response time and resolution time are three separate obligations. A vendor can acknowledge a P1 ticket within 15 minutes and still take 9 hours to restore service. Each needs its own target, measurement point and consequence in the SLA schedule. For banks running digital services, POJK 21 of 2023 (issued 19 December 2023), Article 26, requires a customer enquiry and complaint function that operates 24 hours a day. A 24x7 response tier therefore has a regulatory basis; it isn't just a preference.

Cloud service credits refund the hosting bill, not the loss

On 19 October 2026 we read the credit schedules of the three providers with a Jakarta region: Google Cloud asia-southeast2, AWS ap-southeast-3 and Azure Indonesia Central. The figures below are for the multi-zone tier, meaning VMs spread across two or more zones.

The middle tier differs: 25% at Google Cloud and Azure, 30% at AWS, for availability from 95% to just under 99%. The pattern is what matters. At all three providers the same 10% band stretches from 99.99% down to 99.0%. In a 30-day month, a 5-minute outage and a 432-minute outage, more than 7 hours, earn identical compensation.

The credit is also calculated on the bill for the affected service, not on your loss. Google Cloud calls its SLA the "sole and exclusive remedy"; credits go against future bills, must be claimed within 60 days, and are capped at that service's monthly charge. AWS states that credits don't entitle you to any refund or other payment. Azure is the most explicit: no credit is given for lost revenue, operational costs or any indirect losses.

A worked example with illustrative numbers: if the channel's compute bill is Rp100 million a month, a 7-hour outage earns a Rp10 million credit, deducted from next month's invoice. The bank's actual loss from those 7 hours is failed transactions, contact-centre load and reputational exposure. We found no figure for the hourly cost of an Indonesian bank channel outage in any primary source from OJK, Bank Indonesia or BPS. Work it out from your own transactions per hour and cost per transaction, and don't borrow an overseas number from a vendor blog.

The upshot: financial protection against an outage doesn't come from the hyperscaler's SLA. It has to come from the contract with your channel vendor and from the architecture, and that contract should tie penalties to outage duration, not to a percentage of the hosting bill.

RTO and RPO: the clauses to ask for

Uptime and recovery are two different promises. A provider can meet 99.9% and still lose the last 4 hours of data when something fails. POJK 11/2022 sets no RTO or RPO figure; the term RTO doesn't even appear in its text. The bank sets the numbers itself through its business impact analysis. PADK 1 of 2026 (issued 23 January 2026, in force 1 March 2026, revoking SEOJK 21/SEOJK.03/2017), Attachment I, Chapter IV.B.3.a.1)c) on business impact analysis, point (4), lists what the BIA must analyse: MTD and/or RTO, plus RPO. The SLA's job is to carry those numbers into the vendor's obligations. The clauses we recommend asking for:

1. RTO and RPO in minutes, per critical service, matching the bank's BIA results.
2. A joint DRP test at least once a year with the vendor taking part. POJK 11 Article 18(3) requires annual testing of critical applications, and PADK 1/2026 Chapter IV.B.3.b says the test "perlu melibatkan" (should involve) the IT service provider when the bank uses one.
3. For cloud-based vendors, evidence of a geographically separate data recovery centre with documented RTO and RPO. SEOJK 29/SEOJK.03/2022 (27 December 2022), Attachment I.c, control 2.h, puts that duty on the bank: it must make sure its cloud provider has one. The obligation is the bank's, not the provider's, which is exactly why it belongs in the contract. The contract is the only lever the bank has for demanding the evidence.
4. Incident notification from vendor to bank within hours, well under 24, because POJK 11 Article 60(1)(a) gives the bank 24 hours from discovery to send OJK its initial notification.
5. Backup frequency and restore tests, with the results reported.

We set out the control types and the evidence documents for DR in types of cyber security in Indonesia and their proof.

How the SLA schedule carries OJK's mandatory contract items

POJK 11/POJK.03/2022 (issued 6 July 2022), Article 30(3), requires a bank's agreement with an IT service provider to address at least 9 items, letters a to i. None of the nine mentions an SLA. The SLA comes in by another route: Article 30(5)(c) on performance assessment, whose elucidation states that a performance-level agreement is known as a service level agreement, and PADK 1/2026 Attachment I Chapter V.B.3.a.5), which lists "jaminan tingkat pelayanan (Service Level agreement/SLA)" among the minimum contents of the standard agreement, including when ownership of the bank or the provider changes. Breaching Article 30(3) carries sanctions under Article 33, up to a ban on launching new products.

For insurers and multifinance companies, POJK 4/POJK.05/2021 (issued 9 March 2021) is more direct. Article 21(2)(h) lists 11 things the institution must secure from its provider, and item 10 is meeting service levels in line with the service level agreement. SEOJK 22/SEOJK.05/2021 (24 August 2021) adds that the SLA must survive a change of ownership.

The mapping below is our reading of both regimes, not OJK text. Its purpose is to let compliance point to one article for each part of the SLA schedule.

Two rows are easy to miss: subcontracting and termination. If your application vendor runs on a third-party cloud and CDN, Article 30(3)(d) requires the bank's written approval of that subcontracting. And if the vendor's SLA rests on a hyperscaler's SLA, the figure promised to the bank can't be higher than the chain underneath it unless the architecture adds redundancy. Article 30(4)(c) also places data and API location among the security requirements the agreement must carry.

What to do before you sign

For the Head of Digital: convert every percentage in the draft SLA into minutes per month using the table above, then ask how many minutes of maintenance are excluded. If the answer is more than 240 minutes a week, the 99.99% on the cover page doesn't mean much. Ask for a customer-side measurement point, separate response from resolution, and tie penalties to duration, not to the hosting bill.

For compliance: check that every row in the mapping table has a clause you can point to, and that monthly SLA reports are kept as evidence of the performance assessment under Article 30(5). That article is about assessing performance, so the evidence is the reports and the follow-up on them, not the contract alone. An examiner who finds a tidy contract and no monthly reports is looking at a gap, not at compliance.

SLA penalties and fees end up in the procurement budget; we cover how to price them into the owner's estimate in HPS (owner estimate) for a website or app. If you're preparing a new channel, our team builds cloud-native applications and enterprise websites, and we can help draft the technical part of the SLA schedule with your IT team.