Game fault reporting in the UK asks how a fault was detected and how long it was active. What UKGC expects, and how to have the answer before it breaks.
Game fault reporting: how long was your game broken?
Picture a Friday afternoon at a UK-licensed operator. A player writes to support: in a popular slot, the trigger symbols landed, but the free spins round never started. Support passes it on. By Monday, the provider confirms it. The game has a fault, and players have been losing a feature they had already won.
Now the compliance lead has five working days and a report to file. The regulator’s guidance lists what that report must cover, and two of the first questions are simple to read and hard to answer.
How was the fault detected? And how long was it active?
The honest answer to the first one is “a player told us.” For the second one, most teams have no answer at all. This article walks through what game fault reporting to the UK Gambling Commission actually asks for, why most operators and providers cannot answer it well, and what has to be in place before the next fault, not after it.
This article summarises public UKGC guidance. It is not legal advice
What UKGC asks after a game fault
The Gambling Commission’s guidance on remote game and software faults is short and specific. Any game fault that affects the player return of a game must be reported as a key event, through eServices, as a “Gaming system fault.” The deadline is “as soon as reasonably practicable and in any event within five working days” of becoming aware of it.
The report is expected to include:
| What the guidance asks for | What you need to answer it |
| The nature of the incident and how it was detected | A record of who or what found it first |
| When the game or version was released | Release history per game |
| When the fault occurred and how long it was active | A timestamp before the fault and a timestamp of the first failure |
| How the fault occurred and how it passed internal and external testing | Root cause, plus an honest view of what testing covered |
| How many players were affected, with the financial amount and the calculation | Session and transaction data for the whole window |
| The difference between expected and actual RTP | Game performance data |
| For a B2B supplier: how many B2Cs offered the game, and whether all were affected | A view of the game on every operator that offers it |
| What remedial action has been or will be taken | The fix, and how you will catch it next time |
The default remedy is just as clear: reimburse the affected players directly. In the regulator’s words, “You should not benefit from a fault.”
One scope note matters. This duty covers faults that change what a game pays. A game that simply fails to load is a different problem, handled under other obligations. The rest of this article is about the faults that land in this report.
Most teams can answer only one of these questions
Look at that table again and ask a practical question. Which rows can a typical operator fill in from the data it already has on Monday morning?
Transaction data covers the player numbers and the amounts. The provider can explain the root cause. But the rows about detection and duration depend on something most teams never recorded: what the game looked like to a player, on that site, before anyone complained.
The reason is structural. The provider sees its own game server. The operator sees its own site and its own wallet. Between them sit the integration, the configuration for each market and the frontend on each device. A fault can start in any of those layers, and each side’s logs show only its own half.
So the start of the fault window is usually set by guesswork. It becomes “since the last release,” or “since the last time someone looked.” And the B2B row is harder still. A provider that cannot see its game on every operator cannot say which B2Cs were affected. It can only say which ones complained.
How a player complaint turns into a longer fault
The regulator’s guidance names the ways a fault gets found: post-implementation reviews, the operator’s own monitoring, and player complaints. It is also open about which of these it prefers. “Detecting minor variances using your monitoring processes would demonstrate you have very effective processes in place.” And: “Prompt identification, game deactivation and notification of faults increases confidence that you are properly monitoring your products.”
A fault found through a complaint is, by definition, a fault that players found first. And the cost of that grows with every day it stays live.
Take an illustrative example and swap in your own figures. A bonus round fails to start in one market. 1,200 sessions a day hit the fault, and the average value of the lost feature is €1.50 per session. That is €1,800 a day to reimburse.
| Faund by | Days active | Illustrative amount to reimburse |
| Monitoring, on the first day | 1 | about €1,800 |
| A player complaint, on day 9 | 9 | about €16,200 |
| A regulator question, on day 30 | 30 | about €54,000 |
The reimbursement is only the visible part. Every extra day also adds more players to contact, more transactions to recalculate, and more engineering hours spent proving which side caused the fault. And it weakens the one thing the report is meant to show: that the business is watching its own games.
A manual check is not a detection process
In June 2026, the Commission settled with a slot supplier for £122,835. Sixteen of its games spun faster than the 2.5-second minimum, some of them for years. The root cause, as the regulator’s notice put it, was the testing method. The supplier had been relying on “a manual stopwatch to measure the speed of their games.” The Commission called that unacceptable, “with all the technological resources available to an online gambling business.”
The lesson for game fault reporting is not about spin speed. It is about method. A check done by hand, from time to time, leaves no reliable record of when a problem started. It also cannot scale to every game, every operator and every market.
Screen-level failures are sanctioned too. In October 2025, an operator paid a £240,000 penalty because some of its games did not show players their net position and celebrated returns that were equal to or lower than the stake. These were problems a player could see on the screen, and the regulator treated them as failures to meet its technical standards.
Both cases point the same way. The regulator expects a business to know what its games do in front of players, and to know it before a player or an investigator does.
What a fault record needs before the fault happens
Before looking at any tool, including PlayPatrol, it helps to set out what a record needs so that it can answer the report’s questions. Five conditions cover most of it:
- It sees the player’s side. Server logs show transactions. They do not show what the player saw on the screen.
- It runs on a schedule, not on suspicion. A check that only runs after a complaint cannot tell you when the fault started.
- It covers every place the game is offered. Every operator, every market and every device that matters, because a fault in one integration can be absent from all the others.
- It keeps timestamped evidence. The last clean check and the first failed check set the limits of the fault window.
- It belongs to neither side. When the operator and the provider disagree about the cause, a record that both can open and trust shortens the argument.
Here is how those conditions map to the report:
| Report question | What answer it |
| How was it detected? | A scheduled check that found it, with the date and the evidence |
| When did it occur, and how long was it active? | The last clean check and the first failed check |
| What remedial action will be taken? | A re-check after the fix, recorded the same way |
| How many B2Cs offered the game, and were all affected? | The same check, run on every operator that offers the game |
Where PlayPatrol fits in a fault report
PlayPatrol is independent monitoring for iGaming, through the player’s eyes. The patrol opens the operator’s site, logs in with a test account, launches the game and plays it the way a player does, on a regular schedule, on the sites and in the markets you name.
Every run is recorded. When a patrol finds a problem, the finding comes with: video, annotated screenshots, network traces, root cause & reproduction steps, forwardable run page.
For fault report, that record does three things:
- It dates the fault. The last clean run and the first failed run set the limits of the fault window, and both come with evidence.
- It shows the spread. For providers, Operators Network Patrol checks the same titles on every operator you name, so the B2B question “were all B2Cs affected?” can be answered with evidence for each of those operators.
- It is independent. PlayPatrol belongs to neither the operator nor the provider, and the run page looks the same to both and to anyone they forward it to.
It is just as important to say what PlayPatrol does not do. It does not measure RTP, and it does not file key event reports. Not every fault is visible on the screen either: a fault that changes an amount by a few cents may only show in game performance data. PlayPatrol records what a player sees, so that the people who file the report have facts to work from.
What changes when the fault record already exists
Go back to the Friday afternoon. With a record in place, the compliance lead opens the run history on Monday morning. The answer to “how was it detected?” is a scheduled check, not a player. The answer to “how long was it active?” sits between two dated runs. The provider can tell every operator whether its site was affected, with evidence for each one, instead of waiting for each operator’s support team to report back. The finance team calculates the reimbursement for a window with clear limits, not for everything since the last release. And the report itself tells the regulator what it most wants to hear: the business found its own fault.
Game fault reporting: questions compliance teams ask
The key event duty in this guidance covers faults that affect the player return of a game. Other problems, such as a game that does not load, fall under other obligations. Your compliance team should confirm the scope for each case.
Both can have duties. The guidance expects a B2B supplier that reports a fault to say how many B2Cs offered the game and whether all of them were affected.
As soon as reasonably practicable, and in any event within five working days of becoming aware of the fault.
No. PlayPatrol records what a player sees when the game runs on the live site. RTP monitoring is a separate process built on game performance data.
No. The report stays with the licensee. PlayPatrol provides the recorded evidence the report can draw on.
Prefer to see it first? Book a demo and watch the patrol play your games.
The compliance lead from the start did not have a reporting problem. The report form was clear. What was missing was a record from before the complaint: something that had watched the game on that site, in that market, on a schedule, and kept the evidence.
The form asks how the fault was detected. It asks how long the fault was active. The answer has to exist before the fault does.
As soon as reasonably practicable, and in any event within five working days of becoming aware of the fault.
The compliance lead from the start did not have a reporting problem. The report form was clear. What was missing was a record from before the complaint: something that had watched the game on that site, in that market, on a schedule, and kept the evidence.
The form asks how the fault was detected. It asks how long the fault was active. The answer has to exist before the fault does.
If a game broke on one of your sites last night, when would you find out?
PlayPatrol plays your games on the live sites and in the markets you name, and keeps a dated record of every run. Get started
