Pith. sign in

REVIEW 3 major objections 5 minor 34 references

LLMs can name the failed microservice with high accuracy yet still pick recovery actions that do not fix the incident.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Even when RAG-based LLMs identify the right root-cause service 91–99% of the time, their recovery-action validity stays only 37–60% on a 302-incident Kubernetes benchmark.

T0 review reviewed 2026-07-11 challenge →

load-bearing objection Clean empirical result: strong LLMs diagnose Online Boutique faults well but often pick invalid recovery plans; the framing is useful, the gold-action labels are the main soft spot. the 3 major comments →

arxiv 2607.04623 v1 pith:XISSDKXZ submitted 2026-07-06 cs.SE cs.DC

Can LLMs Really Recover Microservice Failures? A Recovery-Aware Evaluation of Diagnosis-to-Action Reasoning

Jiaxing Qi , Zhongzhi Luan , Hongyu Zhang , Shaohan Huang , Carol Fung , Yongxin Tong , Hailong Yang , Depei Qian This is my paper
classification cs.SE cs.DC
keywords microservicesfault diagnosisrecovery planningrecovery-aware evaluationLLMsroot cause analysisKubernetesincident response
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Recovery from a cloud-native microservice failure is not finished when the root cause is known. An operator or agent must still choose a concrete operation, bind it to an admissible target, and restore service health. This paper argues that existing root-cause and log evaluations stop too early: they score diagnosis, not that next action decision. The authors introduce R2Act, a framework that packages multi-modal incident evidence, incident-specific action spaces, valid and invalid recovery plans, offline validity checks, and live replay. On 302 audited Kubernetes incidents, the strongest retrieval-augmented language models reach roughly 91–100% root-cause service accuracy, yet recovery validity stays only about 37–60%. Even after both the service and the fault type are correct, methods still choose invalid plans for roughly 40–62% of those cases. The gap is largest on DNS, HTTP, and memory faults, where the right fix depends on dependency, configuration, or resource semantics rather than a simple restart. The paper’s claim is that many recovery failures come from translating diagnosis into a valid operation and target, not from missing diagnostic knowledge, and that recovery validity must be measured as a first-class objective.

Core claim

Diagnostic correctness does not imply recovery-action validity. On the same 302 quality-audited incidents, the strongest RAG-based language models reach 91.4%–99.7% root-cause service accuracy while recovery validity remains only 36.8%–60.3%. Conditioning on incidents where both root-cause service and fault type are correct still leaves an invalid-action rate of 39.5%–62.0%. The dominant error modes are wrong operations and invalid plan structure, especially for DNS, HTTP, and memory faults.

What carries the argument

R2Act: a recovery-action evaluation layer that, for each incident, defines an incident-specific action space and counts a predicted plan as valid only when its operation, target, and optional fields match an annotated valid plan and stay inside that space, with offline validity further checked by validity-gated live replay.

Load-bearing premise

The gold valid recovery plans and incident-specific action spaces, built from the injected fault specification and expected post-recovery state, correctly define what counts as a valid fix for each incident.

What would settle it

On the same incidents, show methods that keep high root-cause accuracy while also exceeding roughly 60% recovery validity after correct diagnosis—especially on DNS, HTTP, and memory cases—or show that the annotated valid plans omit operator-accepted alternatives that restore health at comparable rates.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • Recovery-oriented systems must be scored on operation hit, target hit, exact plan match, and recovery validity, not only on root-cause service or fault-type accuracy.
  • Even near-perfect localization leaves a large post-diagnosis action-decision residual that richer logs, events, and metrics alone do not close.
  • Future methods need explicit models of operation semantics, dependency endpoints, configuration scopes, and resource limits, not free-form mitigation text attached to RCA labels.
  • Offline recovery-validity labels and live replay are complementary checks: a plan must be admissible before execution success is credited.
  • Benchmark construction can reuse audited multi-modal incidents with typed action spaces so new recovery methods are compared under identical constraints.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Production auto-remediation that trusts high RCA accuracy without an action-validity gate will still execute many wrong restarts and incomplete dependency repairs.
  • The hardest fault classes here (DNS, HTTP routing, memory limits) map to the same places human operators need runbooks that name scopes and endpoints, not only the failed service.
  • A natural next test is whether teaching models the typed action schema and admissible targets during training or tool use shrinks the post-diagnosis invalid-action rate without harming RCA accuracy.
  • If equivalent operator-validated plans can be added to the valid set, the measured gap may shrink somewhat, but the need for action-level metrics would remain.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper argues that recovery-oriented microservice incident response requires evaluating post-diagnosis action decisions, not only root-cause localization. It introduces R2Act, a framework with an incident schema, quality gate, incident-specific action spaces, recovery-validity metrics, offline evaluation, and live replay, instantiated as 302 quality-audited Online Boutique/Kubernetes incidents with multi-modal evidence and annotated valid/invalid recovery plans. Across heuristic, supervised, RCA, deep-log, and LLM methods, the strongest RAG LLMs reach 91.4%–99.7% root-cause service accuracy but only 36.8%–60.3% recovery validity; even after correct service and fault type, 39.5%–62.0% of plans remain invalid. Errors concentrate on wrong operations and plan structure, especially DNS/HTTP/memory faults, and validity-gated live replay for Qwen-RAG recovers 146/302 cases.

Significance. If the measured diagnosis-to-action gap is not an artifact of label construction, the paper makes a clear and useful contribution: it separates RCA correctness from recovery-plan validity and supplies a reusable evaluation layer (schema, action spaces, validity metric, offline evaluator, live replay) that existing RCA/log benchmarks lack. Strengths include progressive RQs that condition on correct RCA, a transparent RCA-to-action mapper used only as a control, an error taxonomy, per-fault breakdowns, quality-audit trails, and executable live checks. These make the work a solid starting point for recovery-aware evaluation of LLM ops agents, even as a controlled single-system benchmark.

major comments (3)
  1. [§III.C, Eq. (4), Table II] §III.C and Eq. (4) define recovery validity via incident-specific P+_i / P-_i / A_i built from the Chaos Mesh injection specification, affected K8s/dependency object, and expected post-recovery state (Table II). This is load-bearing for the central claim that residual E_C (Table VI: 0.395–0.620 after correct service+type) reflects diagnosis-to-action reasoning failure rather than label mismatch. Live replay (RQ5) re-injects the same Chaos object and thus confirms executability of those labels, not that they exhaust operator-valid recoveries. Please strengthen justification of gold semantics: (i) state how many plans typically sit in P+_i and how equivalents were validated; (ii) report sensitivity if common operational alternatives (e.g., restart/redeploy for some DNS/HTTP cases) are admitted; (iii) qualify absolute gap magnitudes when labels are injection-derived undo policies.
  2. [Figure 7, Table VII, RQ4] Figure 7(b) shows recovery validity = 0.00 for both DNS fault and DNS random across all five RAG backbones, while RCA-Service remains 0.88–1.00. Combined with Table VII (67.9% wrong operation), this is the sharpest empirical support for the gap—but also the strongest risk that gold actions (repair DNS/dependency endpoint) are schema-narrow relative to free-form model outputs that may be operationally reasonable. Please analyze a sample of DNS predictions: are failures mostly wrong operation type, missing dependency fields, or format/schema mismatch? Without this, the claim that failures arise from translating diagnosis into admissible targets is hard to separate from action-space rigidity for dependency faults.
  3. [§III.A, §VII, Abstract] The manuscript evaluates a single application (Online Boutique), six services, and eight injected fault categories (§III.A; Limitations §VII). The framework/schema separation is a good design choice, but the title and abstract claim about recovering “microservice failures” and LLM recovery ability rest on this one controlled population. Please either (a) add at least a second system or fault-campaign family under the same schema, or (b) more tightly bound claims to “controlled Online Boutique fault campaigns” in abstract/conclusion and discuss how organization-specific recovery policies would change A_i and P+_i.
minor comments (5)
  1. [Abstract] Abstract retains the LaTeX placeholder “\system”; replace with Online Boutique for the camera-ready abstract.
  2. [Figure 3] Figure 3 quality-gate box has the typo “consistency verrification” (should be verification).
  3. [Figure 2] Figure 2 packs many method labels into a small scatter; consider a legend or jitter/annotation so points are readable in print.
  4. [§V Evaluation Metrics, Table IV] Clarify in §V whether Exact Match requires a single canonical gold plan or any member of P+_i, and how that relates to Recovery Validity in Eq. (4); Table IV’s large Exact vs Valid gap suggests set-valued acceptance, but the text could state this once explicitly next to the metrics.
  5. [§VI.E RQ5] RQ5 reports full live replay only for Qwen-RAG. A short note on why that backbone was chosen and whether a second backbone was spot-checked would help readers judge generality of the 48.3% replay-consistent rate.

Circularity Check

0 steps flagged

No circular derivation: empirical gap between RCA accuracy and recovery validity is measured against independently scored plan labels and live health checks, not forced by redefinition of the metrics.

full rationale

R2Act is an evaluation framework and empirical study, not a first-principles derivation. The central claim—that high root-cause service/type accuracy (e.g., 91.4%–99.7%) coexists with much lower recovery validity (36.8%–60.3%), and that E_C remains 39.5%–62.0% after correct service+type—is obtained by scoring method outputs against incident-specific valid/invalid plan sets (Eq. 4) and, for Qwen-RAG, against validity-gated live replay health restoration. Recovery validity is defined separately from RCA-Service/RCA-Type (Action Hit, Target Hit, Exact Match, Valid, No-op; conditional V_C and E_C), so the reported diagnosis-to-action gap is not true by construction. Gold plans and action spaces are built from Chaos Mesh injection specs, affected objects, and expected post-recovery state (§III.C, Table II); that is standard controlled ground-truth construction for a fault-injection benchmark, not a self-definitional loop in which the measured quantity is fitted or renamed from the diagnostic labels. The fixed RCA-to-action mapper is applied only to RCA-only methods as a transparent diagnostic control (Gold RCA + Mapper V_C = 0.599), not as a claimed optimal policy or as a prediction derived from fitted parameters. There is no uniqueness theorem, ansatz smuggled via self-citation, or load-bearing self-citation chain that forces the gap. Concerns that P^{+}_i may encode injection-specific undo rather than all operator-valid recoveries are construct-validity / label-completeness issues, not circularity of a derivation chain. Steps empty; score 0.

Axiom & Free-Parameter Ledger

4 free parameters · 4 axioms · 3 invented entities

The paper is an empirical systems evaluation, not a first-principles derivation. Load-bearing content is mostly domain assumptions about Kubernetes recovery semantics, quality-admission rules, and how gold valid plans are defined from injected faults. Free parameters are experimental design choices (window, intensities, action catalog) rather than fitted physical constants. Invented entities are evaluation constructs (R2Act schema/metrics), not physical objects.

free parameters (4)
  • 75-second post-recovery health window
    Live-replay success depends on this chosen observation window; different windows could change recovered counts without changing offline plan labels.
  • Quality-gate modality completeness product qi
    Admission of the 302 main incidents depends on hand-specified completeness checks; excluded warning/failed/pilot runs alter the evaluation population.
  • Fixed RCA-to-action mapper policy
    Maps fault types to restart/scale-out/memory-limit/config-rollback/dependency-restart rules; action scores for RCA-only methods are policy-dependent by construction.
  • Candidate recovery action catalog (7 ops / 5 gold-used)
    The discrete action space and required target fields define what counts as valid; expanding equivalent operator plans would change validity rates.
axioms (4)
  • ad hoc to paper A recovery plan is valid iff it lies in the incident-specific valid plan set P+_i, not in P-_i, and inside action space A_i.
    Equation (4) and §III.C define the paper’s primary success criterion; the central gap claim is measured against this definition.
  • domain assumption Gold valid plans can be constructed from the Chaos Mesh injection specification, affected object, and expected post-recovery state.
    §III.C treats injection-derived recovery semantics as ground truth for admissible operations/targets.
  • domain assumption Online Boutique on Kubernetes with six service roles and eight fault categories is a sufficient controlled proxy for studying diagnosis-to-action recovery evaluation.
    §III.A and §VII limitations; all reported numbers come from this single testbed.
  • domain assumption Standard Kubernetes recovery primitives (restart, scale-out, rollback, memory-limit increase, config rollback, DNS/dependency repair) cover the recovery decisions under study.
    Table II enumerates the action vocabulary used for labels and evaluation.
invented entities (3)
  • R2Act evaluation framework no independent evidence
    purpose: Package incident schema, quality gate, action-space representation, recovery-validity metrics, offline evaluator, and live-replay protocol for post-diagnosis recovery assessment.
    Primary methodological contribution; independent evidence is the released benchmark design and reported experiments, not external prior formalization.
  • Recovery Validity metric (valid(p̂)) no independent evidence
    purpose: Score whether a predicted operation-target plan is admissible for a specific incident beyond RCA labels.
    Central dependent variable for the diagnosis-to-action gap; defined by the paper’s action-space annotations.
  • Incident-specific action space A_i with annotated valid/invalid plans no independent evidence
    purpose: Enumerate admissible recovery decisions and hard negatives for each incident.
    Enables action-level scoring; constructed for this benchmark rather than observed from production operator traces.

reviewed 2026-07-11 · how reviews work

0 comments
Cite this review

Pith. "Pith review of Can LLMs Really Recover Microservice Failures? A Recovery-Aware Evaluation of Diagnosis-to-Action Reasoning." pith.science (2026). https://pith.science/paper/XISSDKXZ

@misc{pith2026260704623,
  author       = {Pith},
  title        = {Pith review of: Can LLMs Really Recover Microservice Failures? A Recovery-Aware Evaluation of Diagnosis-to-Action Reasoning},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XISSDKXZ}},
  note         = {Machine review of arXiv:2607.04623}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

Large language models (LLMs) are increasingly used to interpret operational evidence and assist incident response in cloud-native microservice systems. However, recovery-oriented use cases require more than identifying a root cause. After observing symptoms and diagnosing a fault, an operator or agent must translate the diagnosis into a concrete recovery action, apply it to an admissible target, and verify that service health has been restored. Existing RCA and log-analysis evaluations are well-suited to diagnosis, but they do not characterize this subsequent action decision. This paper presents R2Act, a recovery-action evaluation framework for post-diagnosis incident response. R2Act defines an incident schema, quality gate, action-space representation, recovery-validity metrics, offline evaluator, and live-replay protocol. We instantiate the framework as a benchmark dataset of 302 quality-audited Kubernetes incidents from \system. Each incident provides synchronized multi-modal observations, root-cause labels, an incident-specific action space, and annotated valid and invalid recovery plans. We evaluate heuristic, supervised, RCA-oriented, deep log, and LLM-based methods. The strongest RAG-based LLMs reach 91.4\%--99.7\% root-cause service accuracy, yet their recovery validity remains only 36.8\%--60.3\%. Even when both the root-cause service and fault type are correct, recovery-oriented methods still choose invalid actions for 39.5\%--62.0\% of correctly diagnosed incidents. Overall, this work reveals that many recovery failures arise not from missing diagnostic knowledge, but from the difficulty of translating diagnostic evidence into valid recovery actions and admissible targets. This work provides a reproducible, simplified starting point for research and evaluation.

Figures

Figures reproduced from arXiv: 2607.04623 by Carol Fung, Depei Qian, Hailong Yang, Hongyu Zhang, Jiaxing Qi, Shaohan Huang, Yongxin Tong, Zhongzhi Luan.

Figure 1
Figure 1. Figure 1: R2Act adds a recovery-action evaluation layer after diagnosis, [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: The plot compares diagnostic accuracy and recovery-action validity on [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: R2Act operationalizes an action-level evaluation layer for microservice incident response. It builds audited incidents from fault campaigns and [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Example standardized benchmark instance. The compact exhibit shows [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Proportional composition of the 302 quality-audited incidents by root [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Characterization of the benchmark dataset. (a) Distribution of gold recovery plans across operation types. (b) Log-scale distribution of root-cause [PITH_FULL_IMAGE:figures/full_fig_p007_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Per-fault difficulty across RAG-based LLM backbones. Panel (a) [PITH_FULL_IMAGE:figures/full_fig_p009_7.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

34 extracted references · 1 canonical work pages

  1. [1]

    Lever- aging large language models for the auto-remediation of microservice applications: An experimental study,

    K. Sarda, Z. Namrud, M. Litoiu, L. Shwartz, and I. Watts, “Lever- aging large language models for the auto-remediation of microservice applications: An experimental study,” inCompanion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering, 2024, pp. 163–174

    2024

  2. [2]

    Llm-enhanced failure localization in microservices: Integrating multi- modal data and expert interpretation,

    Z. Zhong, R. Fu, M. Ma, S. Zhang, Y . Sun, C. Bansal, and D. Pei, “Llm-enhanced failure localization in microservices: Integrating multi- modal data and expert interpretation,”IEEE Transactions on Services Computing, pp. 1–14, 2026

    2026

  3. [3]

    Bench- marking microservice systems for software engineering research,

    X. Zhou, X. Peng, T. Xie, J. Sun, C. Xu, C. Ji, and W. Zhao, “Bench- marking microservice systems for software engineering research,” in Proceedings of the 40th International Conference on Software Engi- neering: Companion Proceeedings, 2018, pp. 323–324

    2018

  4. [4]

    Microhecl: High-efficient root cause localization in large- scale microservice systems,

    D. Liu, C. He, X. Peng, F. Lin, C. Zhang, S. Gong, Z. Li, J. Ou, and Z. Wu, “Microhecl: High-efficient root cause localization in large- scale microservice systems,” in2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP). IEEE, 2021, pp. 338–347

    2021

  5. [5]

    Interpretable failure localization for microservice systems based on graph autoencoder,

    Y . Sun, Z. Lin, B. Shi, S. Zhang, S. Ma, P. Jin, Z. Zhong, L. Pan, Y . Guo, and D. Pei, “Interpretable failure localization for microservice systems based on graph autoencoder,”ACM Transactions on Software Engineering and Methodology, vol. 34, no. 2, pp. 1–28, 2025

    2025

  6. [6]

    Loghub: A large collection of system log datasets for ai-driven log analytics,

    J. Zhu, S. He, P. He, J. Liu, and M. R. Lyu, “Loghub: A large collection of system log datasets for ai-driven log analytics,” in2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE). IEEE, 2023, pp. 355–366

    2023

  7. [7]

    A large-scale evaluation for log parsing techniques: How far are we?

    Z. Jiang, J. Liu, J. Huang, Y . Li, Y . Huo, J. Gu, Z. Chen, J. Zhu, and M. R. Lyu, “A large-scale evaluation for log parsing techniques: How far are we?” inProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2024, pp. 223–234

    2024

  8. [8]

    Logeval: A comprehensive benchmark suite for llms in log analysis,

    T. Cui, S. Ma, Z. Chen, T. Xiao, C. Zhao, S. Tao, Y . Liu, S. Zhang, D. Lin, C. Liuet al., “Logeval: A comprehensive benchmark suite for llms in log analysis,”Empirical Software Engineering, vol. 30, no. 6, p. 173, 2025

    2025

  9. [9]

    Mrca: Metric-level root cause analysis for microservices via multi-modal data,

    Y . Wang, Z. Zhu, Q. Fu, Y . Ma, and P. He, “Mrca: Metric-level root cause analysis for microservices via multi-modal data,” in Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, ser. ASE ’24. New York, NY , USA: Association for Computing Machinery, 2024, p. 1057–1068. [Online]. Available: https://doi.org/10.1145/...

    doi:10.1145/3691620.3695485 2024

  10. [10]

    Rcaeval: a bench- mark for root cause analysis of microservice systems with telemetry data,

    L. Pham, H. Zhang, H. Ha, F. Salim, and X. Zhang, “Rcaeval: a bench- mark for root cause analysis of microservice systems with telemetry data,” inCompanion Proceedings of the ACM on Web Conference 2025, 2025, pp. 777–780

    2025

  11. [11]

    Logsage: An llm-based framework for ci/cd failure detection and remediation with industrial validation,

    W. Xu, J. Luo, T. Huang, K. Sui, J. Geng, Q. Ma, I. Akasaka, X. Shi, J. Tang, and P. Cai, “Logsage: An llm-based framework for ci/cd failure detection and remediation with industrial validation,” in 2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2025, pp. 3742–3753

    2025

  12. [12]

    Logsieve: Task-aware ci log reduction for sustainable llm-based analysis,

    M. E. Barnes, T. A. Ghaleb, and S. Hassan, “Logsieve: Task-aware ci log reduction for sustainable llm-based analysis,”arXiv preprint arXiv:2601.20148, 2026

    arXiv 2026

  13. [13]

    Openrca: Can large language models locate the root cause of software failures?

    J. Xu, Q. Zhang, Z. Zhong, S. He, C. Zhang, Q. Lin, D. Pei, P. He, D. Zhang, and Q. Zhang, “Openrca: Can large language models locate the root cause of software failures?” inThe thirteenth international conference on learning representations, 2025

    2025

  14. [14]

    Rcagent: Cloud root cause analysis by autonomous agents with tool-augmented large language models,

    Z. Wang, Z. Liu, Y . Zhang, A. Zhong, J. Wang, F. Yin, L. Fan, L. Wu, and Q. Wen, “Rcagent: Cloud root cause analysis by autonomous agents with tool-augmented large language models,”arXiv preprint arXiv:2310.16340, 2023

    Pith/arXiv arXiv 2023

  15. [15]

    Automatic root cause analysis via large language models for cloud incidents,

    Y . Chen, H. Xie, M. Ma, Y . Kang, X. Gao, L. Shi, Y . Cao, X. Gao, H. Fan, M. Wenet al., “Automatic root cause analysis via large language models for cloud incidents,” inProceedings of the Nineteenth European Conference on Computer Systems, 2024, pp. 674–688

    2024

  16. [16]

    A mape-k approach to autonomic microservices,

    A. Bucchiarone, C. Guidi, I. Lanese, N. Bencomo, and J. Spillner, “A mape-k approach to autonomic microservices,” in2022 IEEE 19th International Conference on Software Architecture Companion (ICSA- C). IEEE, 2022, pp. 100–103

    2022

  17. [17]

    Microremed: Benchmarking llms in microservices remediation,

    L. Zhang, Y . Zhai, T. Jia, C. Duan, M. He, L. Pan, Z. Liu, B. Ding, and Y . Li, “Microremed: Benchmarking llms in microservices remediation,” arXiv preprint arXiv:2511.01166, 2025

    arXiv 2025

  18. [18]

    Swe-bench: Can language models resolve real-world github issues?

    C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan, “Swe-bench: Can language models resolve real-world github issues?” inInternational Conference on Learning Representa- tions, vol. 2024, 2024, pp. 54 107–54 157

    2024

  19. [19]

    Secbench. js: An executable security benchmark suite for server-side javascript,

    M. H. M. Bhuiyan, A. S. Parthasarathy, N. Vasilakis, M. Pradel, and C.-A. Staicu, “Secbench. js: An executable security benchmark suite for server-side javascript,” in2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2023, pp. 1059– 1070

    2023

  20. [20]

    Root cause analysis for microservice system based on causal inference: How far are we?

    L. Pham, H. Ha, and H. Zhang, “Root cause analysis for microservice system based on causal inference: How far are we?” inProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, 2024, pp. 706–715

    2024

  21. [21]

    Pyrca: A library for metric-based root cause analysis,

    C. Liu, W. Yang, H. Mittal, M. Singh, D. Sahoo, and S. C. Hoi, “Pyrca: A library for metric-based root cause analysis,”arXiv preprint arXiv:2306.11417, 2023

    Pith/arXiv arXiv 2023

  22. [22]

    Logprompt: Prompt engineering towards zero-shot and interpretable log analysis,

    Y . Liu, S. Tao, W. Meng, F. Yao, X. Zhao, and H. Yang, “Logprompt: Prompt engineering towards zero-shot and interpretable log analysis,” in Proceedings of the 2024 IEEE/ACM 46th international conference on software engineering: Companion proceedings, 2024, pp. 364–365

    2024

  23. [23]

    Leveraging rag-enhanced large language model for semi-supervised log anomaly detection,

    W. Zhang, Q. Zhang, E. Yu, Y . Ren, Y . Meng, M. Qiu, and J. Wang, “Leveraging rag-enhanced large language model for semi-supervised log anomaly detection,” in2024 IEEE 35th International Symposium on Software Reliability Engineering (ISSRE). IEEE, 2024, pp. 168–179

    2024

  24. [24]

    Rcaflow: A workflow-informed hierarchi- cal planning multi-agent system for root cause analysis,

    Y . Gao, Z. Cai, and B. Yang, “Rcaflow: A workflow-informed hierarchi- cal planning multi-agent system for root cause analysis,” inProceedings of the AAAI Conference on Artificial Intelligence, vol. 40, no. 1, 2026, pp. 300–308

    2026

  25. [25]

    Grace: A strategic llm-enhanced graph reinforcement learning framework for adaptive fault recovery in microservice systems,

    R. Chen, Y . Pu, J. Xin, J. Wang, X. Liao, K. Zhang, and W. Wu, “Grace: A strategic llm-enhanced graph reinforcement learning framework for adaptive fault recovery in microservice systems,” in Service-Oriented Computing: 23rd International Conference, ICSOC 2025, Shenzhen, China, December 1–4, 2025, Proceedings, Part I. Berlin, Heidelberg: Springer-Verlag...

    work page doi:10.1007/978-981-95-5012-8 2025

  26. [26]

    Recommending root-cause and mitigation steps for cloud incidents using large language models,

    T. Ahmed, S. Ghosh, C. Bansal, T. Zimmermann, X. Zhang, and S. Rajmohan, “Recommending root-cause and mitigation steps for cloud incidents using large language models,” inProceedings of the 45th IEEE/ACM International Conference on Software Engineering, 2023, pp. 1737–1749

    2023

  27. [27]

    Genkubesec: Llm-based kubernetes misconfiguration detection, local- ization, reasoning, and remediation,

    E. Malul, Y . Meidan, D. Mimran, Y . Elovici, and A. Shabtai, “Genkubesec: Llm-based kubernetes misconfiguration detection, local- ization, reasoning, and remediation,”arXiv preprint arXiv:2405.19954, 2024

    Pith/arXiv arXiv 2024

  28. [28]

    Galr: Graph-based root cause localization and llm-assisted recovery for microservice systems,

    W. Zhang, Z. Yang, F. Peng, L. Zhang, Y . Chen, and R. Chen, “Galr: Graph-based root cause localization and llm-assisted recovery for microservice systems,”Electronics, vol. 15, no. 1, p. 243, 2026

    2026

  29. [29]

    Logformer: A pre-train and tuning pipeline for log anomaly detection,

    H. Guo, J. Yang, J. Liu, J. Bai, B. Wang, Z. Li, T. Zheng, B. Zhang, J. Peng, and Q. Tian, “Logformer: A pre-train and tuning pipeline for log anomaly detection,” inProceedings of the AAAI conference on artificial intelligence, vol. 38, no. 1, 2024, pp. 135–143

    2024

  30. [30]

    Online boutique,

    Google Cloud, “Online boutique,” https://github.com/ GoogleCloudPlatform/microservices-demo, 2026, accessed 2026- 05-17

    2026

  31. [31]

    Kubernetes documentation,

    The Kubernetes Authors, “Kubernetes documentation,” https://kubernetes.io/docs/, 2026, accessed 2026-05-17

    2026

  32. [32]

    Prometheus monitoring system,

    Prometheus Authors, “Prometheus monitoring system,” https://prometheus.io/docs/, 2026, accessed 2026-05-17

    2026

  33. [33]

    Chaos mesh documentation,

    Chaos Mesh Authors, “Chaos mesh documentation,” https://chaos-mesh. org/docs/, 2026, accessed 2026-05-17

    2026

  34. [34]

    Onelog: towards end-to-end software log anomaly detection,

    S. Hashemi and M. M ¨antyl¨a, “Onelog: towards end-to-end software log anomaly detection,”Automated Software Engineering, vol. 31, no. 2, p. 37, 2024

    2024

This paper was first reviewed by grok-4.5 on July 11, 2026.