Deploy an Azure SRE Agent, break a sample app, and watch it diagnose and fix the issue. ~40 minutes.

Windows: After installing Python, disable Store aliases: Settings → Apps → App execution aliases → turn OFF python.exe and python3.exe

• Active Azure subscription with Owner role
• Register: az provider register -n Microsoft.App --wait

• GitHub account — fork dm-chelupati/grubify for Scenarios 2 & 3

The setup.sh script handles everything: login, deploy, and configure.

macOS / Linux:

git clone https://github.com/microsoft/sre-agent.git
cd sre-agent/labs/starter-lab
bash scripts/setup.sh

Windows:

git clone https://github.com/microsoft/sre-agent.git
cd sre-agent\labs\starter-lab
"C:\Program Files\Git\bin\bash.exe" scripts/setup.sh

The script will:

1. Check prerequisites
2. Sign in to Azure (--use-device-code)
3. Sign in to Azure Developer CLI
4. Register resource providers
5. Ask for GitHub username (optional)
6. Deploy infrastructure (~5-8 min)
7. Configure the SRE Agent

If you prefer to run each step yourself:

az login --use-device-code
azd auth login --use-device-code
az provider register -n Microsoft.App --wait

azd env new sre-lab
azd env set AZURE_LOCATION eastus2
# Optional: azd env set GITHUB_USER <your-username>
azd up

bash scripts/post-provision.sh

Open sre.azure.com → Full Setup → verify:

• Code: 1 repository (if GitHub connected)
• Incidents: Connected to Azure Monitor
• Azure resources: 1 resource group
• Knowledge sources: runbook files indexed

Break the app and ask the agent to investigate using logs and knowledge base.

# macOS/Linux
bash scripts/break-app.sh

# Windows
"C:\Program Files\Git\bin\bash.exe" scripts/break-app.sh

1. Open the Grubify frontend — try adding to cart (it's broken!)
2. Start a new chat → type / → select any custom agent
3. Send:

   The Grubify API is not responding — specifically the "Add to Cart" is failing. 
   Can you investigate, find the root cause, and create a GitHub issue with your detailed findings?
   

4. Agent investigates: searches memory, queries KQL, references runbook, identifies memory leak
5. Ask: Can you mitigate this issue?
6. Verify recovery in browser

Automated Alert: After 10-15 min, check Activities → Incidents — Azure Monitor may have fired an alert and the agent investigated autonomously.

Same break as Scenario 1, but the agent also:

• Searches Grubify source code for the root cause
• Finds exact file:line causing the memory leak
• Creates a GitHub issue with code references and fix suggestion
• May create a PR with the fix

If the agent can't create an issue, nudge it: Use the GitHub API to create the issue if the direct tool isn't working

# Create sample customer issues (uses gh CLI, no PAT needed)
bash scripts/create-sample-issues.sh <your-user>/grubify

# Or Windows:
"C:\Program Files\Git\bin\bash.exe" scripts/create-sample-issues.sh <your-user>/grubify

1. Go to Builder → Scheduled tasks → triage-grubify-issues → Run task now
2. Check github.com/<your-user>/grubify/issues — each [Customer Issue] gets:
   • Classification: Bug, Performance, Feature Request, Question
   • Labels: bug, api-bug, severity-high, etc.
   • Triage comment from the agent

Try these prompts in a new chat (no /agent needed — the meta agent handles these):

What is the public endpoint URL for the Grubify frontend container app?

Show me the CPU and memory usage trends for the Grubify container app over the last hour

Check if there are any Azure Advisor recommendations for my resource group

What recent changes were made to resources in my resource group? Check the Activity Log.

Using the http-500-errors runbook, walk me through all the diagnostic KQL queries 
and show me the results for the Grubify app

Remember that our on-call rotation is: Monday-Wednesday is Team Alpha, 
Thursday-Sunday is Team Beta. The escalation path is: on-call → team lead → VP Engineering.

Then later ask: Who is on call today?

azd down --purge