An iGaming platform SLA is the clause that quietly decides whether your casino or sportsbook is taking bets during the moments that actually make money. Most operators skim the headline uptime number, sign, and never test what it really promises. This guide explains what a service-level agreement covers in iGaming, the uptime figures that matter in real downtime minutes, and exactly what an operator should demand from a platform or payment provider before committing.
Quick answer: A strong iGaming platform SLA guarantees at least 99.9% uptime (ideally 99.95% or higher), defines planned-maintenance windows, incident response and resolution times, 24/7 support, an escalation path, and service credits for breaches — and it must state whether that uptime covers only the core platform or the game providers and payment rails too.
What an SLA is in iGaming — and why it decides revenue
A service-level agreement is a provider's binding, measurable promise about how available and responsive their software will be, and what happens when they miss. In most industries a few minutes of downtime is an inconvenience. In iGaming it is lost revenue that never comes back: a player who cannot place a bet during a big match, or whose deposit fails at the checkout, does not wait — they leave for a competitor and often do not return. Because your platform holds real money and settles bets in real time, availability is not a technical nicety, it is the direct input to gross gaming revenue. That is why the SLA belongs in your commercial due diligence, not in the small print your lawyer skims after the deal is agreed.
99.9% vs 99.95% vs 99.99%: what each really means
Vendors quote uptime as a percentage because it sounds reassuring, but the only honest way to read it is as downtime minutes per year. The difference between one extra nine is enormous:
- 99.9% ("three nines") — about 8 hours 46 minutes of downtime a year, or roughly 43 minutes a month. Acceptable as a floor, but a single bad incident can eat the whole annual budget.
- 99.95% — about 4 hours 23 minutes a year, or roughly 22 minutes a month. A sensible target for a serious real-money platform.
- 99.99% ("four nines") — about 52 minutes a year, or under 5 minutes a month. This is what tier-one operators expect for the core wallet and betting engine.
The catch is the denominator. "99.9% uptime" measured across a calendar year can hide a two-hour outage during a championship final, because the rest of the year averages it away. Always ask how uptime is calculated, over what window, and whether planned maintenance is excluded from the figure — exclusions are where a generous-looking number goes to die.
What a real iGaming SLA must specify
A one-line uptime promise is not an SLA. A real one spells out every term an operator can hold the provider to:
- Uptime commitment and measurement — the exact percentage, the calculation method, and the reporting cadence.
- Planned-maintenance windows — when maintenance can happen (ideally off-peak for your key markets), how much notice you get, and whether it counts against uptime.
- Incident response and resolution times — how fast the provider acknowledges an issue and how fast they commit to restoring service, graded by severity.
- Escalation path — named contacts and a clear ladder to senior engineers, not a shared inbox.
- Support hours — genuine 24/7 coverage with people, not just a status page, because incidents do not respect business hours.
- Service credits and penalties — what you are owed when the SLA is breached, and how you claim it.
- Scope — the single most-overlooked term: does the guarantee cover the whole player journey, or only the provider's core while game studios and payment gateways sit outside it?
Scope matters because your players experience one product. If the core platform is up but the game aggregator or payment gateway is down, the operator still loses the bet — and a narrow SLA leaves you carrying that risk alone. Clarify at the outset how integrations are covered, which is exactly the kind of contract detail that surfaces during proper iGaming API integration planning.
Peak-event load: why "average" uptime hides the failures that cost you
Availability and capacity are different problems, and the SLA usually only covers the first. A platform can be technically "up" while timing out under load, which is functionally identical to an outage for the player trying to bet. The failures that hurt most cluster around exactly the moments that drive revenue: a major sporting final, a jackpot climax, a marketing push that lands. Average uptime smooths these spikes into invisibility.
So look past the percentage and ask about behaviour under stress. Has the provider load-tested for the concurrency your peak events create? Does the architecture auto-scale, and how quickly? What is the tested transaction throughput of the wallet and ledger when everyone bets in the same ninety seconds? A provider that engineers for peak load answers with numbers and test evidence; one that cannot is selling you an average that will fail when it matters.
Payment and PSP SLA specifics
Payments are where uptime turns directly into cash, so the payment layer deserves its own SLA scrutiny beyond the platform figure. Ask for three distinct commitments: gateway uptime (the availability of the payment integration itself), transaction success rate (the share of deposits and withdrawals that complete without error), and settlement timing (how quickly funds actually move and reconcile). A gateway can be "available" while quietly declining a chunk of deposits, which is why success rate is often the more revealing metric.
Because most operators run several PSPs, the platform should cascade to a backup provider automatically when one degrades, so a single gateway problem never blocks deposits outright. That resilience is a design decision made during casino payment integration, not a setting toggled later — and it is worth confirming a provider builds for it before you sign.
Monitoring, redundancy and disaster recovery (RTO and RPO)
Uptime is an outcome; monitoring and redundancy are how a provider earns it. Expect real-time monitoring and alerting so problems are caught before players notice, redundancy so no single server or component takes the platform down, and a documented disaster-recovery plan for the worst case. Two DR terms belong in plain language in your due diligence:
- RTO (Recovery Time Objective) — how long it takes to get the platform back up after a major failure. Lower is better.
- RPO (Recovery Point Objective) — how much data, measured in time, you could lose in that failure. For a real-money wallet the honest answer should be effectively zero — no settled bet or balance should ever vanish.
Ask when the DR plan was last tested, not just whether it exists. An untested recovery plan is a document, not a safeguard.
Red flags in a vendor SLA and the questions to ask
Some warning signs recur across weak agreements. Treat these as red flags: a bare uptime percentage with no measurement method; planned maintenance excluded from the figure without limit; no service credits, or credits so small the provider is indifferent to breaching; a scope that quietly ends at the core and excludes games and payments; "24/7 support" that turns out to be a ticket queue; and no mention of RTO, RPO or DR testing at all. Vague answers to direct questions are themselves the signal.
Before you sign, ask the provider to show — not just assert — its uptime history for the last twelve months, its incident-response and resolution times by severity, its most recent security audit and DR test, its peak-load test results, and precisely what the SLA covers end to end. A provider confident in its engineering welcomes these questions; one that deflects is telling you something. The same rigor applies when you evaluate the build itself, which is why reliability sits alongside certification in any serious iGaming software development assessment, and in the iGaming certification and testing guide.
How Sudonex approaches uptime and reliability
Sudonex is a B2B iGaming software development company (since 2018) building owned casino, slot, sportsbook, live-casino and crypto platforms for licensed operators across 17 regulated markets. We do not sell a one-size-fits-all uptime badge, because reliability depends on how a platform is architected for your markets and traffic. Instead we engineer for it: server-side wallet and ledger integrity so no settled bet is lost, real-time monitoring and 24/7 operations, redundancy across critical components, and payment integration that cascades across PSPs rather than betting your deposits on a single gateway. Because the technology is owned rather than rented, the SLA, the architecture and the certifications are yours to control. If you are evaluating what reliability you can actually demand — and what a provider should commit to in writing — tell us what you are building and we will scope the platform, integrations and reliability targets for your target markets, usually within one working day.