Find the bad config and draft the rollback

During a simulated outage, an SRE used Gemini CLI to trace logs, identify a bad config push, and prepare the revert and follow-up work.

Done with Gemini· Advanced

What they did
An SRE opened Gemini CLI during a simulated incident and let it pull incident details, line up time-series signals, and inspect logs with internal ProdAgent tools. After the agent suggested a restart plan, the SRE approved it, but the restart did not work. The agent then checked the service source and recent edits, spotted a faulty config push, and drafted a changelist to undo it. A custom command also wrote the postmortem and filed action items through MCP.
How it went
The bad config push was located in under two minutes. After the SRE approved the revert, it went out and the service recovered. The scenario was simulated, and no other timing details were given.
Tips
Keep a person in the loop for every production change. If your stack uses internal tools, you’ll need equivalent typed, policy-checked commands and your own MCP setup.

Try it yourself with Gemini

You are helping with an outage in [service name]. Pull the latest incident data, logs, and time-series signals from [log source], then look for the most recent config change that best explains the failures. Show your evidence and propose a restart or rollback plan. Pause and wait for my approval before you apply any restart, revert, deploy, or other change. After I approve, draft the rollback as [patch / changelist / pull request] and prepare postmortem action items in a format I can review before anything is sent or filed.

Fill in the [brackets]. Agents can make mistakes, so review anything before it is sent, paid or deleted.

Read the original on cloud.google.com ↗

Get 3 agent uses like this every morning

With the day's top AI news. Free, and one click to unsubscribe.