Uptime and incident response

The commitment

The commitment is 99.9%, and it is contractual rather than aspirational — it is in the agreement, not on a slide.

Over a thirty-day month that is an allowance of about 43.2 minutes. The window is the calendar month, so the allowance moves with the month's length rather than being a fixed budget.

A number on its own is the least useful thing a supplier can publish about availability, which is why the rest of this page is longer than this section. Anybody can write a figure. What a figure is measured against, and what happens in the minutes after it stops being true, is the part worth reading.

What it is measured against

Three services, and they are ours rather than the whole product:

• Game launch — POST /games/openGame, the call that puts a round in front of a player.
• The catalogue call — GET /users/{user_id}/getUserGames/{currencyISO}.
• The wallet callback path — our side of the commands we post to the URL you expose.

Our services, in other words: the parts of a round that are ours to keep running. Not your platform, and not the studios' game servers.

The window is a calendar month. Excluded from it:

• Scheduled maintenance, announced in advance.
• Outages inside a third-party studio's own systems. We aggregate content from many studios and a title going down at its source is not something we can commit to on their behalf — though it is something we will tell you about, and something you can disable a title over.

Measured by us. There is no third-party monitor and no public status page. That means the measurement is ours, which is a real limitation on how much weight the number should carry for you, and it is a better thing to know now than to discover during an incident.

If independent measurement matters to your board, that is a fair thing to raise before signature rather than a thing to assume. It is also a fair thing to ask every other supplier you are speaking to, and the answers will be more varied than the published figures are.

What happens during an incident

Whoever sees it first. We watch, and we reach out when we catch something. You will sometimes catch something before we do, and when you do we would rather hear it immediately than have you wait to see whether it clears. Neither direction is guaranteed to be the first one, and a page that claimed otherwise would be describing an alerting pipeline rather than what happens.

Monitoring is a human backstop rather than a system. There is a person looking rather than a pager rota driven by automated thresholds. It is worth stating plainly because the phrase 'we monitor 24/7' is used for both arrangements and they behave very differently at four in the morning.

What you get from us while it is happening:

• You get told what is affected, in the shared channel, as soon as somebody knows.
• You get told when it is not yet understood, rather than waiting for a diagnosis. An unexplained outage you know about is easier to run a support desk against than a silent one.
• You get told when it is over, and what it was.

Who you reach

A shared channel, set up per operator at onboarding. Not a ticket form and not a general inbox — a channel with your people and ours in it, agreed when the integration is set up. It is the route that actually gets used, which is the only property of an escalation path that matters.

Coverage hours are set in your agreement rather than published here. We are not going to put a round-the-clock commitment on a public page and then discover which half of it is true during your first incident. Ask what the hours are before you sign, and get the answer in the agreement.

For anything that is not an incident — a question, a correction to this page, a request to revoke a credential — contact us.

What we ask of you

• An endpoint that stays reachableThe wallet commands go to a URL you expose. If that endpoint is down, rounds stop, and the part of the path that failed is not ours — so the first thing worth checking in an outage is which side of the callback the failure is on.
• A technical contact we can raise an incident withA named person or rota rather than a shared address nobody owns. This is the one thing that most often turns a ten-minute incident into a two-hour one, and it costs nothing to fix in advance.
• A replay you can run safelySettlements are idempotent: a repeated transactionId returns the current balance and applies nothing further, and a rollback for a transaction we have never seen is treated as a success. That is what makes it safe to replay after an interruption rather than reconciling by hand — but only if your side was built to take advantage of it, which is a decision made long before the incident.

What this does not cover

Worth being blunt about, because an SLA from a supplier is routinely read as covering more of the product than it does.

• Your own platform and infrastructure — on an API integration that includes the wallet, the ledger, the front end and the session.
• Your acquirer. If card payments stop, coin purchases stop, and nothing about that path is ours on either route.
• Your identity verification provider. The check is arranged by you with your own provider, on both routes.
• A studio's own game servers, per the exclusion above.

On an API integration almost nothing in the money path is ours. A player buys a package through your acquirer, the balance moves in your ledger, the redemption is yours end to end and we never see it. What we keep running is the catalogue, the launch call and our side of the callback — so this commitment covers a genuinely smaller share of your product than the phrase 'our uptime SLA' tends to suggest, and you should size it accordingly.

There is a remedy if the commitment is missed, and it is set in the agreement rather than published here — the terms differ per deal and a number on this page would be one you had to renegotiate anyway. Ask for it on the first call. It is a fair question and it saves a second one.

The shape of the commercial arrangement this sits inside is on the API integration page.

Reviewed 1 September 2026. Corrections are made visibly rather than silently.