Flashduty is a full-featured incident on-call center. It integrates with monitoring systems across cloud and on-prem environments, centralizes alert noise reduction and routing, supports acknowledgment and escalation, and helps teams coordinate on-call work. We spoke with representative customers to understand their pain points, selection criteria, and expectations for the future.
For this story, we interviewed a senior operations engineer at Tuyoo Games about the company's experience with Flashduty. Game companies such as Tuyoo, Lilith Games, and Yostar share many similar on-call scenarios, so this interview gives a practical look at incident response in the gaming industry.
1. Could you briefly introduce your team and the technical characteristics of your business?
Our business is mainly made up of game projects and platform services. Most of our environments are non-containerized, although some platform services use Kubernetes.
Most game backends are built with Go, Python, Java, and C#. They run on virtual machines or physical servers, and use open-source middleware and databases to support game backend services. Our infrastructure is a mix of multi-cloud resources and IDC environments. Some projects use cloud services and virtual machines, while others run on self-built services. Overall, our monitoring scenarios and requirements are relatively complex.
2. Before Flashduty, how did you send alerts? What were the biggest pain points?
We have long used Falcon and Nightingale. Before adopting Flashduty, we built our own alert delivery proxy to connect Falcon and Nightingale to downstream notification channels.
At the beginning, there was no convergence or noise reduction. We once had a P0 phone alert storm that flooded phones so badly people could only power them off. That was caused by large-scale alert flapping. We also had cases where DingTalk bots were overwhelmed, and SMS alerts made it hard to receive normal text messages.
Later, we added some judgment and convergence logic ourselves. It helped somewhat, but the custom logic still could not converge alerts efficiently enough. It also made the processing logic complicated, and we were worried that bugs in that logic could hide valid alerts.
Another major issue was that our alert delivery service had no on-call scheduling. Every alert went to every operations engineer. That wasted SMS and phone call costs, but the more serious problem was the interruption: sending everything to the whole group badly affected everyone's rest time.
3. You use multiple monitoring systems across cloud and on-prem environments. Are they connected to Flashduty now? How has it worked?
Yes. We connected Nightingale V6 to Flashduty, which helped us implement a real monitoring on-call mechanism and made alert convergence much more convenient and effective.
We also connected cloud platform alerts to Flashduty. That solved the previous problem where cloud alerts could not reliably reach the right people or be handled through an on-call process.
4. Did you run into any issues during the integration? How did you solve them?
The Flashduty integration itself went smoothly and was easy to use. We spent some time customizing alert templates.
For alert statistics and analysis in Flashduty, our first experience was not as convenient as we wanted. Later, by aggregating alert events across different dimensions, such as severity and alert title, the data became much easier to use for on-call review and closed-loop analysis.
5. Which Flashduty features do you value most? Which ones solved real problems for you?
Two features stand out:
- Multi-platform integration. Alerts from different platforms can be sent to one place and handled through one on-call workflow. It works out of the box.
- Alert convergence. With the default convergence configuration, our average noise reduction ratio is above 80%.
6. What advice would you share with teams planning to adopt Flashduty?
Make full use of on-call scheduling and escalation. Define alert ownership clearly: who is the primary owner, who receives the alert, who handles it, and who follows up.
It is also important to let users serve themselves through monitoring, while operations teams provide guidance and training. In our collaboration with development teams, operations plays the role of coach and platform provider. This is a common and healthy organizational model. Self-service by development teams can greatly improve efficiency, as long as there is a strong platform behind it.
7. After using Flashduty for a while, how do you feel about it? Do you have any suggestions?
It works well for us today. In the future, we would like to see more intelligent alert analysis, such as recommendations on which alert rules should be optimized and how. That would help us operate the system more effectively from a data perspective.
Flashduty can already ingest event sources. We would also like event wall capabilities to be integrated more deeply into Flashduty. In production environments, many incidents are related to changes. If change events could be presented in a unified place, it would be a major help for incident diagnosis.
About Flashduty
Flashduty centralizes alert handling and notifies the right person at the right time.
Every minute matters. Reducing downtime protects revenue.
Flashduty integrates with the monitoring systems teams already use.
Timely alert handling is essential for production reliability. A centralized on-call center helps teams reduce alert storms, avoid missing critical incidents, and analyze response efficiency through metrics such as MTTA and MTTR. Try Flashduty for free.
