Praetor · The autonomous SRE commander

When production goes
down, Praetor takes
the call.

Production outages cost enterprises $1–5M per hour. Mean-time-to-resolution averages 8.85 hours. Praetor is an autonomous incident commander — once the alert lands, it investigates, decides, remediates, verifies, and escalates to code if the runtime fix isn't enough. No humans in the loop between page and verdict.

—

Recorded Runs

—

Resolved

Scenario Families

Typed Actions

A three-phase product

One environment.
Three ways to use it.

The same nine-service simulated cluster, the same six-component verifiable reward, three different audiences experiencing it. The LLM agent learning, the human practicing, the real deployed site being rescued.

For ML Researchers

Observatory

Replay any recorded trained-agent run. Inspect the six-component reward decomposition, watch the per-component sparklines rise across the episode, see the action timeline tier-by-tier.

Open observatory →

For SREs & Engineers

Apprentice Mode

Solve the same incidents the AI was trained on. PagerDuty alert lands, you investigate a real-feeling cluster with an AI coach nudging you. Three scenarios, easy to hard.

Start training →

For Hackathon Judges

Real-Time

Plug a real deployed site into the trained agent. Inject a fault, watch ops actions stream in, escalate to code investigation if the site stays degraded. Sim-to-real, live.

Connect a site →

“Six independent reward components, every one a pure verifiable function — no learned reward model, no LLM-as-judge, no exploits.”

— from our hackathon submission · RLVR design note

Why this matters

No public RL environment
existed for SRE incident response.

The market

Every tech company runs an on-call rotation. Outages cost $1–5M per hour at enterprise scale, and MTTR is climbing as systems get more distributed, not shrinking. The observability and incident management market is $45B and the workflow has barely changed in fifteen years.

If the work is methodical reasoning under uncertainty — exactly what RL-trained LLM agents should be good at — why is there no benchmark?

What Praetor is

An autonomous incident commander. Once paged, Praetor investigates with a typed action vocabulary (10 SRE-shaped actions), decides what to fix using the trained policy, executes via the same Backend Protocol that the simulator uses, verifies recovery, and escalates to code investigation if runtime ops aren't enough.

Trained with the hackathon's recommended recipe: SFT warm-start from senior-SRE behavioral-clone trajectories, then GRPO fine-tuning over a six-axis verifiable reward. Same policy runs against the simulator, against a real deployed site, and against the codebase.

Phase 1 · Watch Praetor work

Every page becomes a recorded run.

Each row is Praetor — the autonomous incident commander — attempting one of three scenario families. Pick a run to see the action timeline, the 6-component reward decomposition, and the per-step service map evolve from red to green.

—

Recorded Runs

—

Resolved

—

Avg Score

—

Conditions

Episode —

Run ID

—

Task

—

Seed

—

Model

—

Alert

—

Verdict

—

Score

—

Steps used

—

Reward decomposition RLVR · 6 components

Per-component reward over the episode

Service map final state

🗺️

Pick a run to see services

Action timeline click to expand

▶

Pick a run and hit Replay

Aggregate — success rate by scenario family

Loading aggregate...

Phase 3 · Praetor on a live site

Point Praetor at a deployed site. It takes it from there.

Praetor probes the site, classifies what's wrong on its own, runs the runtime fix, and if that's not enough, opens the codebase you point it at and tells you which lines to look at.

Connect your platform optional — the right path for real production

Praetor isn't a black box that reaches into someone else's infrastructure. It works through a contract. Connect your platform here and Praetor will (1) link your repo for tier-2 code analysis, (2) generate the adapter file you drop into your own deployment, and (3) take over Real-Time once your adapter goes live.

Sign in with your GitHub account to scope tier-2 code analysis to one of your repos. Real OAuth via device flow — no password entry, no callback URL needed.

Generate a praetor_adapter.py file to drop into your own deployment. The adapter implements the /ops/* contract on top of your platform's deployment APIs, so Praetor's trained policy can drive your real services through the same interface that the simulator uses.

Project name

Platform

Services to manage (comma-separated)

Connect to a deployed site

Paste the URL of a site that exposes the operator contract (/ops/health, /ops/restart, etc). The site can be hosted anywhere — Render, Vercel, Fly, HF Space.

No site to point at? Use built-in demo target → (this server's /ops/* endpoints)

Not connected

Praetor's classification

Link your codebase — for tier-2 escalation when ops can't fully heal

For toy sites, runtime ops are usually enough. For real sites at Paytm / Amazon / Airbnb scale, the bug often lives in the code itself. Praetor reads the code only when ops actions don't fully heal the fault.

Run Praetor

Praetor uses the classification it just made. No need to tell it what's wrong — it figured that out.

No fault detected? Inject a test fault →

Live unified timeline tier 1 ops · tier 2 code

⚡

Connect a site and inject a fault

Incident-response simulator · AI-coached

Train to fix production
before it breaks on you

A flight simulator for on-call engineers. You're paged at 3 AM, a real-looking outage unfolds across 9 microservices, and an AI coach nudges you toward the right fix. No production is harmed.

Incident Scenarios

Microservices

SRE Actions

1:1

AI Coaching

The Problem

Production Incidents Are Costing Billions

The status quo is unsustainable — and there is no training ground

$1M-$5M

Cost per hour of downtime for enterprises

8.85 hrs

Average Mean Time To Resolution

65%

Of engineers report burnout from on-call

6 mo

Typical ramp-up time for new SREs

Every tech company operates on-call rotations where engineers are woken at 3 AM to diagnose production outages. There is no safe, realistic place to practice. Engineers learn by making mistakes in production.

How Training Works

Four Steps, Coached End-to-End

A realistic outage, real decisions, instant feedback from your AI coach.

🚨

Alert Fires

You're paged. Alert tells you which services are screaming, not why.

🔍

Investigate

Click the service map. Read logs. Check metrics. Your coach nudges you toward the right clue.

🔬

Diagnose

Trace the dependency chain to find the real root cause — not the surface symptom.

⚡

Remediate

Restart, rollback, or reconfigure. Every decision is scored and explained.

What Makes It Different

An AI Coach in Your Corner

Every mistake becomes a learning moment, not a bruise

💡

Contextual Hints

The coach reads your game state and suggests the next best action — with the reason why.

📘

Plain-English Why

Click "Why?" on any log or metric to get a jargon-free explanation.

🗺️

Visual Service Map

See the cascade spread through the dependency graph in real time.

🏆

Post-mortem Review

Finish an incident, see your grade, compare against a senior SRE's playbook.

Incident Scenarios

3 Scenarios — Easy to Hard

Each one teaches a different diagnostic skill. Unlock progressively.

YOUR FIRST PAGE5 min

OOM Crash

payment-service crashes with OutOfMemoryError. Learn how to read logs, spot memory limits, and restart correctly.

⏱ 15 steps🎯 4 learning goals

TRACE THE CASCADE12 min

DB Pool Exhaustion

Connection leak cascades through the stack. Learn to trace symptoms past the surface to the real root cause.

⏱ 25 steps🎯 7 learning goals

UNDER FIRE20 min

Bad Deployment Cascade

A bad deploy takes out the cluster. Three services failing at once. Learn when to rollback vs restart, and the importance of sequencing.

⏱ 35 steps🎯 10 learning goals

Infrastructure

9-Service Microservices Cluster

Realistic failure propagation through a dependency graph

🌐 Service Topology

frontend-bff → api-gateway ├→ order-service → payment-service │ → inventory-service │ → postgres-db ├→ user-service → auth-service └→ notification-service

📊 Per-Service Simulation

Health states — healthy, degraded, unhealthy, crashed
Live metrics — CPU, memory, latency p50/p99, error rate
Structured logs — timestamped with realistic error patterns
Deployment history — version tracking + rollback
Dependencies — upstream/downstream failure cascading
Resource quotas — CPU/memory limits per replica

💡 Ready to train?

Click Training in the nav bar. Your first-run tutorial will walk you through the UI.

Start with "Your first page" — a simple OOM crash, solvable in ~5 minutes.

Your AI coach appears on the right. Stuck? Click 🤖 Hint. Want an explanation of a log line? Click Why? on any action card.

Finish an incident and see your post-mortem: grade, rubric breakdown, and what a senior SRE would have done differently.

Live Testing

Run Real API Scenarios

Each test makes real API calls to the running environment. Watch the staged execution.

⚡ Health Check

Verify the environment is running and responsive

📋 List All Tasks

Enumerate available incident scenarios with difficulty levels

🔍 Quick Diagnosis

Start an OOM incident, list services, then read error logs from the crashed service

✅ Full Resolution

Run a complete fix: diagnose the OOM crash and restart with more memory

💥 Cascading Failure

Start a DB pool exhaustion incident and trace the cascade from frontend through to the database

An end-to-end
SRE training system,
not just an environment.

A full RL substrate, a behavioral-clone seed dataset, an SFT+GRPO training notebook, an interactive observability dashboard, a sim-to-real bridge, and a tier-2 code escalation module — packaged as one product.

Built for three audiences

Different needs.
Same substrate.

For ML researchers

A clean RL benchmark

OpenEnv-compatible spec with full action_space / observation_space declarations
Six independent reward components — RLVR with no learned reward model to game
Parametric scenario families with seed-deterministic trajectories
Out-of-the-box SFT + GRPO Colab notebook (Qwen2.5-Coder-1.5B, 4-bit LoRA via Unsloth)
Anti-reward-hacking regression tests pinning the four common exploits

For SREs & engineering teams

A flight simulator

Three difficulty-graded scenarios (OOM, DB pool exhaustion, bad deployment cascade)
Real-feeling 9-service cluster with cascading dependencies and live metrics
AI coach that nudges you toward the right move with Why? explanations on every action
Structured post-mortem at the end with senior-SRE comparison
Per-user progress tracking, no production at risk

For hackathon judges

A complete submission

Reward curves across four conditions × three families × thirty seeds (360 episodes)
Sim-to-real demo: same trained policy, deployed HTTP site, real chaos injection
Tier-2 code escalation: when ops can't fully heal, the agent investigates the codebase
268 passing tests covering every critical path
Public Space, Colab notebook, blog, video — all linked in the README

Capability matrix

Every claim, verifiable.

Capability	Where it lives	Verified by
Six-component verifiable reward	`incident_commander_env/server/grading/components.py`	29 unit tests in `test_reward_components.py`
Anti-reward-hacking ×4 exploits closed	`scenarios/` + `actions/handlers.py`	15 regression tests in `test_reward_hacks.py`
Seeded reproducibility	`simulation/cluster.py` + `metrics_engine.py`	3 tests in `test_seeded_reproducibility.py`
Parametric scenario families 3 families	`scenarios/scenario_*.py`	integration tests in `test_environment.py`
Backend Protocol	`server/backends/protocol.py`	19 contract tests in `test_backend_protocol.py`
WebsiteBackend (HTTP) sim-to-real	`server/backends/website.py`	23 mock-HTTP tests in `test_website_backend.py`
Tier-2 code escalation	`training/code_investigator.py`	9 tests with synthetic repo in `test_code_investigator.py`
Episode JSONL traces & observatory	`training/episode_logger.py` + `/runs` + `/watch`	9 tests in `test_observe_mode.py`
Training pipeline (SFT → GRPO)	`training/train_grpo.ipynb`	20 plumbing tests in `test_training_modules.py`

Technical stack

Boring tools.
Sharp choices.

Environment

FastAPI · Pydantic v2

Typed action / observation / state contracts, OpenEnv-compatible reset / step / state surface.

Simulator

Pure-Python cluster

9-service in-memory simulation, deterministic with a seed, zero external dependencies.

Training

HuggingFace TRL · Unsloth

SFTTrainer + GRPOTrainer, 4-bit Qwen2.5-Coder-1.5B with LoRA r=16. Self-contained Colab.

Sim-to-real

HTTP Operator API

Minimal /ops/* contract any deployable site can implement. No Docker required.

Tier 2

Heuristic + LLM

Shallow git clone, scenario-keyword grep, ranked code findings, optional LLM summary.

Frontend

Vanilla, no framework

Hand-written HTML/CSS/JS. Loads instantly, no build step, no bundle.

Telemetry

JSONL episode logs

Every run writes a structured trace under runs/<id>/episode.jsonl. Replayable forever.

Quality

268 tests, < 9 s

Covers every critical path. CI-friendly. Mock-HTTP suites isolate from network.

The incident curriculum

Six fault shapes.
Every one is real.

Praetor's curriculum mirrors the most common production incident classes. Each scenario is parametric — every (seed, difficulty) pair produces a fresh instance — so the agent learns the shape of the fault, not three fixed cases.

OOM Crash

Easy

java.lang.OutOfMemoryError: Java heap space

Fix: restart with a higher memory limit. The agent must spot the OOMKilled pattern, infer the limit was too low, and avoid restarting unrelated services.

Heroku 2014 (Postgres OOM), Reddit 2017 (Cassandra), almost every Java microservice ever.

DB Pool Exhaustion

Medium

PSQLException: pool exhausted (20/20)

Fix: raise pool size + restart the leaking service. The agent must trace symptoms from the user-facing frontend two layers down to the DB before acting.

GitHub 2018, Discord 2020, Shopify 2016 — all cascade-from-DB outages.

Bad Deployment Cascade

Hard

Memory leak v2.4.0 — autoscaler exhausted quota

Fix: rollback the bad deploy before restarting the starved dependents. Action ordering matters. Wrong order is the rubric's whole point.

Knight Capital 2012 ($440M), CrowdStrike 2024 (global Windows outage), Facebook BGP 2021.

Disk Full

Easy

[Errno 28] No space left on device

Fix: restart cycles the volume. The trap is that metrics look mostly fine — only logs reveal the ENOSPC error pattern.

Slack 2020 (logs filled root), GitHub 2018, Stripe 2017 (audit log spillover).

Slow Query / Lock Contention

Medium

Lock wait timeout exceeded; txn rolled back

Fix: rollback the deploy that introduced the slow query. The trap is that restart is a quick fix that doesn't last — the binary still has the bad query.

GitHub 2020 (24h incident, slow query in DB upgrade), Instagram 2017 migration.

TLS Certificate Expired

Easy

ssl.SSLError: certificate has expired

Fix: restart triggers the cert renewal hook. The whole point is that metrics look almost normal. Only the logs (and error rate) tell the truth.

Microsoft Teams 2020, Spotify 2021, Azure DevOps 2018, LinkedIn 2017, Cloudflare 1.1.1.1 2021.

From page to verdict

The autonomous loop, end-to-end.

Once the alert lands, no humans in the loop. Praetor runs the same five-stage cycle a senior on-call engineer runs — except it never sleeps, never panics, and writes a clean trace of every decision.

Page

Alert lands via webhook. Praetor receives POST /reset with the incident task_id + seed.

Investigate

list_services, read_logs, check_metrics, describe_service — picks the right diagnostics for the symptom.

Decide

The trained policy outputs a typed action. Restart vs rollback vs reconfigure — the right one for this fault.

Act

Same Backend Protocol whether the substrate is the simulator or a real deployed site. One trained policy, two execution paths.

Verify

Polls /ops/health for a stable green window. Declares resolved with an accurate root_cause string for the postmortem.

If runtime ops aren't enough — escalate to code When stage 5 doesn't go green, Praetor opens the linked codebase (GitHub, Azure Repos, or uploaded ZIP), greps for files matching the failing service + scenario keywords, ranks suspects, and writes a Code Escalation Report with a suggested fix. Diagnosis-only today; the next step is shipping the patch as a PR.

Endpoints

API Reference

Base URL: http://localhost:8000

POST/resetStart a new incident episode

Request:  { "task_id": "oom_crash" }
Response:
{ "observation": { "message": "INCIDENT ALERT...", "alert": "...", "dependency_graph": {...} },
  "reward": 0.01, "done": false,
  "info": { "task_id": "oom_crash", "max_steps": 15 } }

POST/stepExecute an SRE action

Request:
{ "action_type": "read_logs", "target_service": "payment-service",
  "parameters": { "lines": 50, "severity": "ERROR" } }
Response:
{ "observation": { "message": "Logs for payment-service...", "logs": [...] },
  "reward": 0.03, "done": false, "info": { "step_count": 2 } }

GET/stateCurrent episode state

Response:
{ "episode_id": "uuid", "step_count": 5, "task_id": "oom_crash",
  "incident_resolved": true, "current_score": 0.99 }

GET/tasksList available scenarios (with backstory, goals, prereqs)

Response:
{ "tasks": { "oom_crash": { "skill_tag": "Your first page", "backstory": "...", "learning_goals": [...] }, ... } }

GET/coach/hintRule-based contextual hint for the current game state

Response:
{ "hint": "Next: read_logs on payment-service...", "suggested_action": {...}, "tone": "encourage" }

POST/coach/explainPlain-English explanation of the last observation

Request:
{ "last_action": {...}, "last_message": "...log text..." }
Response:
{ "explanation": "OutOfMemoryError means...", "matched_terms": [...] }

GET/postmortemEnd-of-episode review with criteria, trajectory, and senior comparison

Response:
{ "grade_letter": "A", "score": 0.99, "criteria": [...], "user_trajectory": [...], "ideal_trajectory": [...] }

GET/healthLiveness check

Response: { "status": "ok" }

When production goesdown, Praetor takesthe call.

One environment.Three ways to use it.

Observatory

Apprentice Mode

Real-Time

No public RL environmentexisted for SRE incident response.

The market

What Praetor is

Every page becomes a recorded run.

Episode —

Reward decomposition RLVR · 6 components

Per-component reward over the episode

Service map final state

Action timeline click to expand

Aggregate — success rate by scenario family

Point Praetor at a deployed site. It takes it from there.

Connect your platform optional — the right path for real production

Connect to a deployed site

Praetor's classification

Link your codebase — for tier-2 escalation when ops can't fully heal

Run Praetor

Live unified timeline tier 1 ops · tier 2 code

Final report

Train to fix productionbefore it breaks on you

Production Incidents Are Costing Billions

Four Steps, Coached End-to-End

Alert Fires

Investigate

Diagnose

Remediate

An AI Coach in Your Corner

Contextual Hints

Plain-English Why

Visual Service Map

Post-mortem Review

3 Scenarios — Easy to Hard

OOM Crash

DB Pool Exhaustion

Bad Deployment Cascade

9-Service Microservices Cluster

🌐 Service Topology

📊 Per-Service Simulation

💡 Ready to train?

Run Real API Scenarios

⚡ Health Check

📋 List All Tasks

🔍 Quick Diagnosis

✅ Full Resolution

💥 Cascading Failure

An end-to-endSRE training system,not just an environment.

Different needs.Same substrate.

A clean RL benchmark

A flight simulator

A complete submission

Every claim, verifiable.

Boring tools.Sharp choices.

FastAPI · Pydantic v2

Pure-Python cluster

HuggingFace TRL · Unsloth

HTTP Operator API

Heuristic + LLM

Vanilla, no framework

JSONL episode logs

268 tests, < 9 s

Six fault shapes.Every one is real.

The autonomous loop, end-to-end.

Page

Investigate

Decide

Act

Verify

API Reference

Sign in or start training

Pick your incident

Service map · click any service for details

Your action log

AI Coach

When production goes
down, Praetor takes
the call.

One environment.
Three ways to use it.

No public RL environment
existed for SRE incident response.

Train to fix production
before it breaks on you

An end-to-end
SRE training system,
not just an environment.

Different needs.
Same substrate.

Boring tools.
Sharp choices.

Six fault shapes.
Every one is real.