Benchmarks for site reliability engineering (SRE) agents are typically episodic: one fault is injected, the agent receives an incident task, and its response is scored. Production operation is not. Incidents surface through noisy alerts, overlap in time, and often originate from code or configuration changes. We present SRE-Marathon, a benchmark for long-horizon, continuous SRE operation. An agent is invoked at a fixed cadence with cumulative alert history and a persistent workspace while operating a live two-zone Kubernetes deployment as a fault orchestrator injects overlapping faults according to a seeded, production-calibrated schedule. Curated code and configuration changes deployed through the same build pipeline available for repair. Each run is recorded into a sealed bundle and scored offline: Marathon-Score credits each injected fault for ordered progress through correlation, localization, and repair, with all metrics computed deterministically from recorded system evidence. Across three applications and about sixty faults per run, the best of 10 methods reaches only 41.3 out of 100. Agents often correlate and localize faults, but almost never complete repairs while the faults remain active.
Figures & tables
Figure 1: One SRE-Marathon run using the ReAct ( Yao et al., 2023 ) agent with Kimi K2.5 on Astronomy Shop. Above: every fault from occurrence to revert. Below: the agent’s actions. The wall-clock axis runs longer than a nominal 90-minute run because the schedule drifts (Appendix A ).
Figure 2: Overview of SRE-Marathon. A fault orchestrator continuously introduces problems into a live microservice system under load. The SRE agent observes their effects through telemetry and alerts and interacts with the system only through instrumented tools.
Figure 3: Example fault specification. The highlighted fields define its category, injection mechanism, target service and affected scope, symptom probe, and responsible artifact.
Stage metrics
Median time (s)
Degrad. Level (%)
Cost per run
Risk
Marathon-Score (Out of 100)
Method
Backbone
Corr
Loc
Rep
MTTD
MTTL
MTTR
Tokens
$
Runbook
—
0.658
0.364
0.024
167
267
560
111.0
—
—
0.028
33.5
ReAct
kimi-k2.5
0.694
0.079
0.006
189
283
709
86.9
6.5M
4.02
0.217
25.4
( Yao et al., 2023 )
gpt-5.6-luna
0.419
0.125
0.000
163
293
—
100.8
6.3M
1.45
0.349
16.3
RAG
kimi-k2.5
0.426
0.398
0.000
200
68
—
150.5
569k
0.46
0.015
23.5
( Lewis et al., 2020 )
gpt-5.6-luna
0.199
0.105
0.000
159
65
—
93.5
730k
0.23
0.000
8.2
Table 2: SRE-Marathon leaderboard: each row averages a method’s marathon runs on three microservice applications; the best value per column is in bold.
Figure 4: Agent actions over time during a marathon run: tool calls per invocation, by tier, in ten-minute bins of the schedule, for every method of Table 2 on Kimi K2.5 and for Runbook.
Figure 5: Stage-wise success over time in fault handling. Each panel shows the % of faults injected so far that have been successfully correlated, located, or repaired by each method on Kimi K2.5.
Figure 6: Two marathon runs containing the same fault type and correct remedy. The shaded focal window marks the lifetime of the fault discussed in each case. From top to bottom, the lanes show active faults (grey) and those with a failing symptom probe (black), RCA (Root Cause Analysis) reports, executed repairs, and user-facing service health.
Appendix figures & tables9 assets
Supplementary material from the paper’s appendix.
Appendix
Category and defect subtype
Astro
OB
TT
Total
Example
Code bug
Feature or logic error
48
6
6
60
A new currency lookup omits a supported currency, so requests in that currency receive an incorrect default value.
Incorrect constant or flag
5
6
6
17
A new length limit on cart identifiers is set too low, so the cart rejects identifiers it previously accepted.
Component incompatibility
23
6
6
35
New code reads database rows by column name while the adapter still returns values by position, so the queries fail.
Type, validation, or exception error
29
6
6
41
A new price check reads only the whole-number part of a price, so valid prices below one dollar are rejected.
Backward incompatibility
45
8
8
61
An update changes the request fields a service expects without accepting the older format, so callers still sending it are rejected.
Appendix
Table 3: Catalog faults by category, application, and defect subtype, with an example of each.
Rule
Fires when
Severity
Holds for
Applications
HighRequestErrorRate
5xx share of entry-point requests above 10%
Critical
1m
All
EndpointErrorRate
5xx share of one entry-point route above 50%
Critical
1m
All
HighRequestLatency
95th-percentile latency of a service above 3000 ms
Critical
1m
All
PodStatusError
A container is waiting with a reported reason
Critical
1m
All
FailedPodsDetected
A pod is in phase Failed
Critical
1m
All
DeploymentNotReady
A deployment with replicas requested has none available
Critical
1m
All
Appendix
Table 4: The rule templates of the frozen pack. The condition paraphrases the PromQL expression, and the error-share rules also require a minimum request rate.
Tool
Tier
Function
code_search
Read
Search the source of one service.
get_alerts
Read
Alerts fired in full cumulative alert history, with their labels.
get_topology
Read
The service call graph derived from traces.
kubectl_describe
Read
Describe one Kubernetes object with its recent events.
kubectl_get
Read
Read the current state of one Kubernetes object.
query_logs
Read
Recent log lines of one deployment.
Appendix
Table 5: The published tools by tier. The policy enforcement layer computes every mutating call’s target set from its typed arguments, and every guarded call must name a reported incident.
Alert rule
Action
Reported category
DeploymentNotReady
scale_deployment to 2
deployment
DeploymentReplicasUnavailable
scale_deployment to 2
deployment
DeploymentGenerationMismatch
rollback
deployment
ContainerOOMKilled
restart_pod
code-bug
PodStatusError
restart_pod
code-bug
PodNotReady
restart_pod
code-bug
Appendix
Table 6: Runbook’s rule table in priority order: when an incident’s alerts fire several rules, the first listed wins. The Online Boutique and Train Ticket rules carry an application prefix and take the row of their unprefixed name.
Figure 7: One invocation of Orbit . Alert merging and both publication steps are deterministic, and the model decides only inside the loop. Everything kept across invocations lives in the workspace.
Seed
Venue
Corr
Loc
Rep
MTTD
MTTL
MTTR
Risk
Marathon-Score
Shared
Single-host
0.517
0.121
0.017
231
329
709
0.136
20.1
17
Single-host
0.203
0.034
0.051
202
625
593
0.593
7.3
27
Multi-node
0.455
0.073
0.018
208
324
2486
0.250
17.0
Appendix
Table 7: ReAct on Kimi K2.5, one Astronomy Shop marathon run per seed. Columns are as in Table 2 .
Regime
Runs
Corr
Loc
Rep
Marathon-Score
Short run, 5 faults
6
0.800
0.200
0.500
38.9
Short run, 10 faults
6
0.728
0.283
0.183
34.8
Marathon run, about 60 faults
3
0.694
0.079
0.006
25.4
Appendix
Table 8: ReAct on Kimi K2.5 by schedule regime. A short-run row averages six short runs, two per application, and the marathon-run row averages the three marathon runs of Table 2 . Columns are as in Table 2 .
Figure 8: Every method of Table 2 on Kimi K2.5, and Runbook. Top: executed actions per invocation in the ten-minute schedule bins of Figure 4 ; unlike its act tier, calls that were denied or failed are not counted. Bottom: every executed action of a method’s marathon runs by what it touched, with the total at the bar’s end. An action is on a live fault when its target set holds the faulted service of a fault injected and not yet reverted. Matching is by service, so it says where an action went and not whether the remedy fit.
Figure 9: One outcome per injected fault, by the first rule that matches: handled, meaning all three stages passed; repaired but not handled; acted on, meaning an executed action targeted its faulted service while it was live, but not repaired; located but not acted on; correlated only; or missed. Rows are the LLM-based methods of Table 2 on both backbones, plus the two ReAct short-run rows.
AI coding agents are ubiquitous in engineering workflows amongst industry and academia. Yet, despite their use in app coding, relatively less attention has been paid to their ability to execute on production incident response. This emerging field, termed agentic site-reliability-engineering (SRE) contains benchmarks limited by (1) unrealistic environments, typically toy repositories (2) non-standard framework implementations and (3) simple static verifiers. We introduce Incident-Arena, a human-built benchmark of 20 carefully selected tasks grounded in real-world deployed open source software. Each task deploys a production application to an ephemeral Kubernetes cluster, injecting a fault from the config layer through underlying images, and a sustained load profile given the task requirements. We also present a novel verification method, going beyond static checks to functional verifiers, holding systems level metrics stable, while ensuring repairs are done safely. Agent trials run an average of 2.81M tokens and 41 turns, going beyond existing benchmarks, demonstrating agentic long horizon reasoning. Across 20 tasks and 3 application substrates, frontier models score below 64.3%, with failures extending from diagnosis/localization errors, through incomplete repairs and unsafe regressions.
Andre Fu, Malik Drabla, Leon Liu +5
Abundant AI · Adrenaline AI · Carnegie Mellon University +2
AI agents are increasingly used to diagnose and mitigate failures in production systems, known as agentic Site Reliability Engineering (SRE). Current SRE benchmarks are limited to oversimplistic SRE tasks and are unfortunately hard to extend due to bespoke designs. We present SREGym, a high-fidelity benchmark for SRE agents. SREGym exposes a live system environment built atop real-world cloud-native system stacks, where high-fidelity failure scenarios are simulated through fault injectors. SREGym models the complexity of production environments by simulating (1) a wide range of faults at different layers, (2) various ambient noises, and (3) diverse failure modes such as metastable failures and correlated failures. SREGym is architected as a modular, extensible framework that orchestrates fault and noise injectors across stacks. SREGym currently includes 90 realistic, challenging SRE problems. We use SREGym to evaluate frontier agents and show that their capabilities varies significantly in addressing different kinds of failures, with up to 40% differences in end-to-end results. SREGym is actively maintained as an open-source project and has been used by researchers and practitioners.
Jackson Clark, Yiming Su, Saad Mohammad Rafid Pial +5
University of Illinois Urbana-Champaign · University of Illinois Urbana-Champaign⋄ · University of Toronto†
AI agents are increasingly expected to complete long-horizon workflows that require sustained progress over hours, millions of tokens, and complex environments. Yet current agent benchmarks largely evaluate short-form tasks, such as single pull requests, small tickets, or 5-10 minute exercises, limiting our ability to measure agents' capabilities in planning, long-context understanding, and memory use. We introduce SWE-Marathon, a benchmark of 20 long-horizon tasks spanning software engineering and adjacent technical domains. Each task consists of a unique executable environment, a human-written reference solution, and a multi-layer verification suite. Logged agent attempts average 27.2M total tokens, making SWE-Marathon substantially longer-horizon than existing SWE and command-line agent benchmarks. Current frontier coding agents solve fewer than 30% of tasks. Failures often arise from poor self-verification, self-reported infeasibility, and premature termination. We also observe reward-hacking behavior in 13.8% of rollouts, where agents attempt to exploit the environment or verifier to bypass the intended workflow. SWE-Marathon includes adversarial review of test suites and execution environments, as well as multi-layer checks designed to prevent shortcut solutions. We release SWE-Marathon, evaluation code, and agent trajectories at https://swe-marathon.org/.