Mobile Team's On-Call Automation Journey with n8n Part 1: Let AI Handle the Analysis

Mobile team on-call involved checking Crashlytics, Datadog, app reviews, and VoC every day, analyzing causes, and responding, and this repetitive work alone consistently consumed over 30 minutes a day. Context had to be switched across Slack, Firebase, Jira, Source Code, and GitHub, and the core problem was that tasks requiring human judgment were mixed together with tasks that AI could handle.

First, Claude Skills, which can be tested locally, were used to build a crash and app review analysis flow. The entry point was unified through Slack, and commands like /crash-analytics and /app-review-comment were designed to read messages, perform analysis, and leave results in the thread. For crashes, Firebase notifications were received, and based on the Firebase Plugin and the source code, device info, occurrence count, impact scope, and stack traces were interpreted, along with a summary of causes and suggested fixes.

For app reviews, the review content was summarized and classified into categories based on similarity. Categories were divided into Operations Policy Check Needed, Mobile Team Check Needed, FE Team Check Needed, BE Team Check Needed, Usability Improvement, and Performance Issue, and managed in an n8n Data Table, allowing even long reviews or large numbers of reviews to be quickly reviewed via AI summaries.

Afterward, to overcome the limitation of requiring a human trigger, automation was moved to n8n. It's free to use when self-hosted, offers high workflow visibility, and made integration easy with existing tools like Slack, Jira, GitHub, and AI. However, during adoption there were issues such as the internal firewall, Firebase Crashlytics access permissions, and Slack bot Event Subscription URL restrictions, which were resolved through scheduling workarounds, configuring HTTP calls via analysis of the open-source Firebase MCP, and separating out a Router workflow.

The operating approach was also designed not to analyze everything automatically, but to filter out only what matters.

• Crashes are selected based on criteria such as occurrence count, app version, and device info
• A team-designated emoji is left on unnecessary messages to reduce token waste
• Source code is fetched via API and summarized only when analysis is needed
• Results are organized into crash cause, impact, suggested fix, additional actions, and a summary of the user environment

Going forward, plans include caching to reduce GitHub calls, refining review category accuracy, exploring reviews of other companies' apps, and even tracking the correlation between Datadog and incident tickets. Ultimately, the goal is to connect crashes, app reviews, and app performance in a three-dimensional way to reduce MTTD and MTTR, evolving on-call so that people can focus more on areas that require judgment.