Who this is for
Operators who run a casino or sportsbook on a platform we delivered, on turnkey or turnkey sportsbook terms, and operators on another platform who need a second line behind their own engineers. Support takes over where our 30 days of launch hypercare end, working from the runbooks written for the handover.
This page covers the application: the platform, its integrations and the changes made to it. Servers, storage, networks and capacity are a hosting service with its own service levels. Player-facing work, such as answering a player whose withdrawal is late, belongs to managed operations. Keep the three apart in the contract, or each provider will point at the other during an outage.
What gets monitored
Server health alone says little on a gambling platform. A server can be healthy while no player in one of your markets can deposit. We monitor what the player and the regulator would notice:
- The player's route, end to end: registration, login, KYC upload, deposit per payment method, game launch per studio, bet placement and settlement, withdrawal request.
- Every integration separately: each game studio, each odds feed, each PSP and acquirer on the gateway, the KYC provider. An outage at one supplier should open an incident with that supplier, not a vague alert about errors.
- Wallet consistency: balances in the wallet against the sum of transactions, and rounds opened at a studio against rounds settled.
- Compliance functions: self-exclusion checks, geo-blocking, deposit limits, KYC thresholds, and any data feed the licence requires, such as Tobique's bi-weekly encrypted backup to the Commission's provider.
- Expiry dates: TLS certificates, domain renewals, and the test certificates and supplier certificates the licence depends on.
Severity levels that fit a gambling platform
Severity scales borrowed from general IT rank incidents by users and revenue affected. On a licensed platform that is the wrong order: a broken self-exclusion check costs nothing in the first hour and can cost the licence. Agree the levels before the first incident, in writing, with examples from your own markets.
| Level | Examples on a casino or sportsbook | What it triggers |
|---|---|---|
| 1, critical | Deposits or bet placement down for a market; wallet balances not matching transactions; self-exclusion, geo-blocking or deposit limits not enforced; live odds stale while markets stay open | Engineers on the incident immediately, the operator's named contact called, affected markets or games suspended, decision on regulator notification |
| 2, major | One PSP or one studio down while alternatives work; withdrawals queuing; back-office reports the regulator relies on producing wrong figures | Engineers on it in working and on-call hours, supplier escalation, player messaging agreed with support |
| 3, minor | A single game failing to launch; a bonus misconfigured for one segment; slow back-office pages | Fix in the next scheduled change, workaround documented |
| 4, request | Configuration changes, new report fields, cosmetic defects | Planned as a normal change |
The response and resolution times against each level belong in your SLA. We do not print ours here, because a single-market Anjouan casino and a multi-market sportsbook with live betting on weekend evenings need different cover, and a figure that fits one misleads the other.
Escalation: who decides what
An incident goes wrong when nobody knows who may take the decision that stops it. Write these down per level:
- Who may suspend a market, a game or a payment method. The platform must be able to do it. The draft GLI-19 v4.0 standard, issued for public comment on 7 July 2026, lists the ability to disable or suspend gaming activity and to void or cancel games among its gaming management requirements. The person who may press the button is a contract question.
- Who calls the supplier. Studios, feed providers and PSPs each have their own support desks and their own severity scales. We open and chase the supplier ticket, so you do not have to.
- Who tells the regulator, and when. That is the licence holder's duty and the licence holder's decision. Support supplies the timeline, the scope and the list of affected players.
- Who tells the players. A status message written by an engineer at night is rarely the one you want published. Agree templates per incident type in advance.
Every level 1 and level 2 incident ends with a written root-cause report: timeline, cause, players and transactions affected, and the change that prevents a repeat.
Change management on a certified platform
Many incidents follow a change. On a gambling platform a change can also alter something a test lab certified, so change control is a compliance process as well as an engineering one. We classify changes in three groups:
- Standard: repeatable and pre-approved, such as adding a game already certified for the licence or switching a payment method on for a market.
- Normal: assessed, tested, approved by both sides and scheduled outside peak hours, with a rollback plan written before the change starts.
- Emergency: to stop a level 1 incident, approved by a named person on each side and documented afterwards.
Certification raises the stakes. The GLI-19 v4.0 draft lets an adopted change management programme determine the scope of modification testing, which makes a documented change process worth money at the lab. On the Isle of Man, new gaming systems no longer need GSC approval before launch, but since 12 July 2024 the operator must send the test certificates and an updated test certificate master list to the GSC first. Anjouan requires notification of any material change, and Tobique requires monthly compliance change reports. The details sit with technical certification; the support team's job is to flag which changes trigger them before they ship, not after.
Freeze windows follow the sports calendar. A release on the afternoon of a major final is an avoidable risk, so the event calendar for your markets is part of the change calendar.
What an SLA should contain
The Google SRE book draws a useful line: an SLO is a target, and an SLA is a contract with consequences for meeting or missing it. If missing the number costs the provider nothing, it is an SLO, whatever the document is called. Check every clause below against any proposal, ours included.
| Clause | What it should say | What to watch for |
|---|---|---|
| What is measured | Named indicators: successful deposits, bet placement, game launches, logins, per market | "Platform availability" measured as a server responding, which stays green while players cannot pay |
| Where it is measured | From outside, along the player's route, per market | Measurement inside the provider's own data centre |
| How it is calculated | Percentiles for speed, not averages; the measurement period stated | Averages, which hide the slowest requests, the ones players complain about |
| Exclusions | Third-party outages listed by supplier, with the provider's duty to escalate even when excluded | A blanket exclusion of "third-party services", which removes studios, feeds and PSPs from the count |
| Maintenance | Windows fixed in advance, notice period, a cap on their number | Unlimited "scheduled maintenance" that does not count as downtime |
| Response and resolution | Separate times per severity level, and what counts as resolved | Response times only, so the clock stops at the first reply |
| Consequences | Service credits or other remedies, and the right to terminate after repeated breaches | Credits capped so low that a breach is cheaper than prevention |
| Reporting | A monthly report against every indicator, and root-cause reports by a fixed deadline | Reports only on request |
Questions to put to any provider, including us
- Who answers at three in the morning on a Sunday: an engineer who can change the platform, or a dispatcher who opens a ticket?
- Show us a root-cause report from a real incident, anonymised.
- Which of your indicators would have gone red during your last level 1 incident, and how long after it started?
- Which changes in the last quarter needed a regulator notification or a lab retest, and who flagged them?
- What happens to support if we move to another platform or another provider takes over?
Frequently asked
Do you support platforms you did not build?
Yes, as a second line behind your own team or the original vendor, after a review of the architecture, the integrations and the monitoring that exists. The review tells both sides what cover is realistic before anyone signs an SLA.
What is the difference between technical support and hosting?
Hosting keeps the servers, storage and network running and sized for your traffic. Technical support keeps the application working: the platform, its integrations and its changes. They need separate service levels because they fail for different reasons.
Do you publish SLA figures?
Not on this page. Response and resolution times are agreed per contract against your markets, verticals and peak hours, and they go into the contract with remedies attached. A figure on a website with no consequence attached is a target, not an SLA.
Who notifies the regulator after an incident?
The licence holder. We supply the timeline, the cause and the list of affected players and transactions, in the form the licence's reporting asks for, so the notification is not held up waiting for facts.
Does a platform update need recertification?
Some do. It depends on whether the change touches a certified component and on the licence. On the Isle of Man, new gaming systems need test certificates sent to the GSC before launch. We flag those changes in the change calendar so a release does not wait on a lab.