Designing a LiveOps alerting system to reduce production incidents cover
← Case study · Tactile Games2 min read

Designing a LiveOps alerting system to reduce production incidents

Role
Product Designer
Duration
3 months
Team
Product Manager, CTO, 2 BE Engineers, 1 FE Engineer
Skills
Product Design, Product Strategy, Prototyping
22%fewer incidents
Problem
Things broke in production, and the people who shipped them were the last to know.
What I did
I put failures where creators already work, and gave every one of them an owner.
Outcome
22% fewer production incidents. Failures now surface in minutes, not hours.

Live mobile games rely on continuous updates after release.

At Tactile, updates are managed through an internal LiveOps Dashboard, where teams configure events, experiments, player targeting, and feature rollouts without shipping new app versions.

Creator schedules a reward
!Critical: reward not deliveredRewards service timed out · View issue →
Holiday bonus500 coins to all playersScheduleStatus: live
Backend delivers it
Delivered
Player gets 500 coins
Ideal flow — A creator schedules a reward, the backend delivers it, and the player gets it.

The problem

Failures were detected by backend systems, but not surfaced in the LiveOps Dashboard.

Goal

Surface backend failures to LiveOps creators early so they can act before players are affected.

Discovery

Critical signals lived outside the LiveOps Dashboard

Engineering tools
Monitoring!
Logs!
Slack!
Support tickets!
Player metrics!
LiveOps Dashboard
Hello, DianaNo alerts
Experiments
Game items
Illustration — Every engineering tool flagged the failure. The Dashboard, where creators actually work, showed nothing.

Solution

Add password to keep reading.