Papers for

it operations teams

Papers whose findings have a practical use for this group, as judged from the abstract. Open a paper to read what it means in practice.

Cognitive debt grows as ai speeds up software development

Cognitive Debt in the GenAI Era - Listening to Practitioners' Voices on the Loss of Understanding

Abstract: Fast-paced AI-assisted software development risks reducing developers' understanding of the systems they build. This growing gap between what the system does and what developers understand about it, described as ``cognitive debt'', is not new, but AI has exacerbated it. This has led to a recent surge in blog posts and online discussions, in which practitioners recognize and write about cognitive debt, and share their experiences well before academic studies can capture them. To understand their concerns and inform future research and practice, we conduct a grey literature review of 76 sources, focusing on how cognitive debt is conceptualized and manifests, its contributing factors, its consequences, and the practices to prevent, detect, and mitigate it. We find that cognitive debt can accumulate unnoticed behind working code and passing tests, particularly when developers accept AI-generated solutions without building understanding. Practitioners report consequences such as harder maintenance and debugging, fragmented knowledge in the team, and reduced productivity. They propose practices such as documenting design rationale, review-sized changes, comprehension gates, and knowledge-sharing rituals, along with signals like reliability metrics to detect it. Our findings give software teams a structured view of emerging practical approaches in AI-assisted development and stress the need to preserve human understanding alongside faster code production.

Tue 27 OctSoftware Engineering
The gist
When developers use AI to help them write software faster, they can start to lose track of how the system actually works. This gap between the system’s behavior and the developer’s understanding is called "cognitive debt." The authors looked at many online posts from practitioners who share how this problem happens, what troubles it causes like harder bug fixing and teamwork issues, and ideas to reduce it such as better documentation and team discussions.
Open → 2610.37888v1

CrowdStrike update caused crashes on millions of Windows devices

CrowdStrike Channel File 291: An Engineering Analysis of a Global Endpoint Outage

Abstract: On July 19, 2024, a CrowdStrike Falcon content update caused Windows systems to crash, affecting about 8.5 million devices according to a Microsoft estimate. The immediate defect was an inconsistency between a detection template that declared 21 inputs and sensor code that supplied 20. A new matching criterion exposed an unchecked array access in the kernel-mode content interpreter. This article reconstructs the incident from vendor technical reports, Microsoft's crash analysis and recovery guidance, congressional records, and operational impact reports. It distinguishes documented findings from engineering inferences and examines how interface validation, test selection, deployment policy, and recovery dependencies interacted. Four assurance gaps were consequential: validation against a definition the consumer did not meet, tests that avoided the missing input, distribution without health-gated promotion, and recovery paths requiring connectivity that some crashing hosts could not maintain. Recommended controls separate defect prevention, exposure containment, and service restoration, with verification criteria, release-cadence constraints, and operational tradeoffs. The case shows why configuration consumed by privileged software requires lifecycle assurance comparable to code, and why release reversion, endpoint recovery, and service restoration must be assessed separately.

Fri 23 OctSoftware Engineering
The gist
A software update from CrowdStrike Falcon in July 2024 caused many Windows computers to crash because part of the update expected more data than it received, which led to errors deep inside the system. The authors analyze official reports and details to explain why this happened and how different safety checks and recovery plans failed to prevent widespread problems. They identify four main gaps that allowed the crashes to spread and describe ways to better prevent, detect, and recover from such incidents. Their work shows why software configurations deserve careful management and testing similar to code itself.
Open → 2610.32078v1

Large language models tested on network device routing setups

An Experimental Study on the Functional Correctness of Network Device Configurations Produced by Large Language Models

Abstract: This paper presents a preliminary study on the efficacy of network device configuration produced by Large Language Models (LLMs). Currently, the study focuses on routing protocol configurations in a predefined small internetwork with Cisco-based routing devices. The capability of three freely available LLMs with standard capabilities (i.e., with no enhanced features) to produce effective setups is investigated. Prompt engineering methods are excluded in order to assess the "first-response" configurations of the models under consideration. The assessment method is based on the contents of the resulting routing table, aiming at measuring the device functional correctness. For that purpose, the Jaccard index is used to indicate the percentage of correct network prefixes contained in the routing table constructed by the model-based configuration commands. The work provides insights on the maturity and limitations of modern LLMs on aiding network administrators with network device configurations in real deployments.

Wed 14 OctNetworking and Internet Architecture
The gist
Setting up network devices correctly is important but can be hard. This paper looks at how well large language models (LLMs) do when asked to create routing setups for network devices without any extra help. The researchers checked the accuracy of these setups by comparing the resulting routing tables to the correct ones. They found that while LLMs can generate some valid configurations, there are clear limits to their current reliability for real-world network management. This work helps understand how useful LLMs might be for network administrators in practical situations.
Open → 2610.19958v1

Benchmark measures summarization of IT incident logs from synthetic data

SLS-Bench: A Benchmark for Incident Log Summarization with Synthetic Observability Data

Abstract: As IT systems grow in complexity, automated agent-driven incident response becomes increasingly critical. A key capability for these agents is summarizing large log streams into human-readable reports. Further progress requires meaningfully evaluating this function, yet existing benchmarks leave end-to-end summarization from large log streams underexplored due to the prohibitive cost and complexity of collecting real-world data. We introduce SLS-Bench, a benchmark for incident log summarization featuring 90 tasks grounded in real-world incident reports, each with a synthetic log stream and a reference summary. To construct SLS-Bench, we developed a data generation pipeline that converts incident reports into structured incident models, which guide the generation of synthetic logs and reference summaries. This pipeline combines narrative grounding, explicit incident modeling, generator-verifier loops, and statistical comparisons with real-world log streams to produce realistic and controllable observability data. Our evaluation of 14 LLMs on SLS-Bench shows that while frontier models can produce useful summaries, they do so at substantial cost and latency, and open-weight models lag significantly. SLS-Bench provides a framework for systematic evaluation of log analysis agents and a scalable blueprint for future synthetic observability benchmarks.

Mon 12 OctArtificial Intelligence
The gist
As computer systems become more complex, it’s important for automated tools to turn long sets of error logs into easy-to-understand reports. The authors created SLS-Bench, a test set of 90 examples where synthetic log data is paired with summary reports based on real incidents. They developed a way to generate realistic fake log data that matches real-world patterns using models and verification steps. Testing different large language models shows some can create helpful summaries, but with delays and high costs, while smaller models struggle more. This benchmark helps measure and improve tools that analyze large IT incident logs automatically.
Open → 2610.16412v1

Deep learning models compared for spotting cloud system anomalies early

Benchmarking Deep Learning Models for Anomaly Detection in Real-World Cloud Telemetry

Abstract: Modern cloud platforms generate high-dimensional, noisy telemetry from thousands of microservices. Unlike classical anomaly detection benchmarks, cloud anomalies are short-lived, irregular, and largely non-periodic, making timely detection challenging. We present an empirical benchmark of deep learning models for anomaly detection using a real-world IBM Cloud Console dataset. We evaluate GRU, Transformer, TimesNet, and Autoformer architectures using the Numenta Anomaly Benchmark (NAB), a timing-aware metric that accounts for early detection and false alarms. TimesNet achieves the highest NAB scores due to strong early-detection sensitivity. Transformer models also detect anomalies early but incur higher false-positive rates. An improved GRU autoencoder, incorporating robust scoring and persistence rules, achieves competitive performance with a more stable false-alarm profile. Overall, the modest performance differences suggest that real cloud anomalies are dominated by short-term deviations rather than persistent periodic structure, emphasizing the importance of timing-aware evaluation and robust post-processing.

Sun 11 OctMachine LearningDistributed, Parallel, and Cluster Computing
The gist
Cloud platforms create huge amounts of data that can be messy and hard to interpret. The authors studied how well different deep learning tools can find unusual patterns or problems in this data quickly. They found that some models catch early signs better but may make more mistakes, while others are more steady but less sensitive. Overall, real cloud problems often look like brief changes rather than ongoing patterns, so it’s important to detect issues fast and carefully handle false alarms.
Open → 2610.15818v1

Software methods compared to spot performance drops early

Evaluating Change Point Detection Methods for Software Performance Regression Analysis

Abstract: Performance issues in software systems are a critical quality issue that can erode user trust, violate service-level agreements, and ultimately affect business efficiency. Consequently, software performance engineering has shifted its focus to developing robust techniques to detect performance regressions as early as possible in the development cycle. Performance regression analysis often relies on time series of performance measurements to detect significant changes in performance behavior. Change Point Detection (CPD) methods have been widely used to automate the identification of such changes in various domains, including finance, healthcare, and performance monitoring. However, the effectiveness of these methods for software performance measurements has not been thoroughly evaluated. In this paper, we present a comprehensive study to evaluate the effectiveness of various CPD methods on real-world software performance measurement datasets. We start by collecting performance measurement data from three large software systems and characterizing the unique properties of performance time series data. Then, we undertake a large-scale effort to annotate and evaluate the consistency of human annotators' identification of potential performance changes. Thereafter, we evaluate the accuracy of twelve distinct CPD methods in detecting potential performance changes, providing insights into their applicability and effectiveness in software performance regression analysis.

Tue 6 OctSoftware Engineering
The gist
Keeping software fast and reliable is very important for users and businesses. The authors studied how well different techniques can automatically find moments when software slows down or behaves worse, by looking at data collected over time. They gathered real performance data from big software projects and checked how people spot these slowdowns by hand. Then, they tested twelve different methods to see which ones do the best job at finding these changes. This helps people pick the right tools to catch problems early in software development.
Open → 2610.09023v1

Llms learn when to stop gathering evidence before closing investigations

Not Until the Evidence Says So: Teaching LLM Investigators When to Close a Case

Abstract: Accident, defect and outage investigations end with a decision that ordinary question answering never faces: whether the evidence gathered so far is enough to close the case. We study this decision for LLM investigators, which request evidence from a case file, revise their hypotheses, and either close the case with a conclusion grounded in what they read or leave it open and name what is missing. This judgment does not come with capability: an untrained 9B model overstates its evidence in 97% of its answers, and a frontier model that identifies the right cause in 84% of cases still overstates in 91% and closes 17 of the 41 cases whose official finding is "cause undetermined". Measuring it is also non-trivial: the source of a case largely predicts its label, and a rule that reads only the source reaches 83.0 balanced accuracy on our test cases. We therefore evaluate closure with three tests: closure accuracy, reported against this rule and within each source; evidence dependence, which removes the grounds of a conclusion and checks whether the model stops closing; and conclusion and gap quality, a judged checklist of what the model asserts and what it says is missing. We build Nautil, 731 audited cases from aviation, rail, maritime, chemical-safety and vehicle-defect reports and production server incidents, with teacher trajectories, an out-of-distribution test set and counterfactual evidence versions. Fine-tuning a 9B model on these trajectories makes its closures follow the evidence: removing the grounds lowers its closure rate by 26 points relative to a matched control, overstatement falls from 97% to 35%, and correct, non-overstated conclusions rise from 3% to 43%. Reinforcement learning that rewards only the closure decision then raises balanced accuracy from 69.2 to 83.3, on par with the teacher, and within-source accuracy from 60.4 to 74.1, at some cost in evidence dependence.

Fri 2 OctComputation and LanguageArtificial IntelligenceMachine Learning
The gist
Investigations often need to decide when they have enough evidence to conclude, which is different from just answering questions. The authors show that large language models (LLMs) usually say they have enough evidence even when they don't, especially without training. They created a dataset of real-world investigation cases and taught a model to better recognize when to end an investigation based on evidence. After training, the model became much better at knowing when to stop and avoiding overconfident conclusions.
Open → 2610.03190v1

Computer use agents improve tasks by combining gui and command line

HybridCUA: Learning to Orchestrate GUI and CLI for Computer-Use Agents

Abstract: Computer use agents (CUAs) have demonstrated strong capabilities in completing digital tasks. However, existing CUAs either rely solely on graphical user interface (GUI) interactions, which are often inefficient and error prone, or augment GUI interactions with application specific APIs or tools, which require substantial engineering effort and are difficult to scale across applications. We argue that the next generation of CUAs should combine GUI interactions with the command line interface (CLI), leveraging the generality of the GUI and the efficiency of shell commands. A critical challenge, however, is that current models do not know when or how to use the CLI during task execution. To address this challenge, we develop a data construction pipeline that produces three types of trajectories: GUI only, CLI only, and interleaved GUI and CLI trajectories. This pipeline results in HybridCUA-8K, containing 5K hybrid trajectories and 3K verified RLVR tasks. Building on these data, we propose a training framework with two stages: supervised fine tuning on the constructed trajectories, followed by reinforcement learning with our CLI aware rewards that encourages agents to use the CLI selectively and reliably. Experiments show that HybridCUA-9B achieves 53.6% accuracy on OSWorld, improving over the base model by 14.8 percentage points, and improves performance on WindowsAgentArena by 4.0 percentage points. These results demonstrate the effectiveness and cross platform generalizability of the hybrid GUI and CLI paradigm for computer use agents.

Tue 29 SeptComputer Vision and Pattern Recognition
The gist
Computer use agents help people complete tasks on computers automatically, but they usually use either only the graphical interface or special apps that need lots of programming. This paper shows a better way by teaching agents to use both the graphical interface and command line together, taking advantage of each method's strengths. The authors created a large dataset to teach these agents and trained them to know when to use commands to be more efficient. Their improved agent works better across different computer systems, proving this mixed approach is useful.
Open → 2609.38008v1

Dynamic graph anomaly detection with adaptive agent control under delayed feedback

DynGraphAgentBench: A Benchmark for Agentic Lifecycle Control in Dynamic Graph Anomaly Detection

Abstract: Dynamic graph anomaly detection requires repeated decisions as graph structure and class prevalence drift, yet detector benchmarks usually score a fixed pipeline after current labels are known. We introduce DynGraphAgentBench, an executable benchmark for agentic lifecycle control under delayed feedback. It comprises seven temporal graph datasets with node- and edge-level anomaly tasks, eleven selectable detectors, and eight chronological deployment windows per dataset. In each window, a controller sees only time-causal aggregate context, registered model cards, and its own matured history. It must choose a detector before current-window training or candidate scores exist. A sandboxed executor trains the chosen architecture on mature data, scores a hidden deployment window, and releases the outcome after a one-window delay. A deterministic verifier checks decision timing, leakage guards, legal actions, training scope, and persisted artifacts. We measure detection utility with average precision and capture at fixed review depth, and characterize adaptation through model switches and compute. Complete eight-window trajectories from two primary controllers and a no-memory reference on four datasets, together with three additional controllers on three datasets, expose useful, costly, and ineffective reactions to delayed evidence without granting an exhaustive current-window oracle.

Sun 27 SeptMachine Learning
The gist
Detecting unusual patterns in networks can be tricky when the network changes over time and labels come late. The authors created DynGraphAgentBench, a test setup where decision agents pick detection methods as new data arrives and know only past information. This setup checks how well agents adapt through multiple time steps, deciding which technique to use before seeing current results. By running with various datasets and controllers, the authors show different ways agents succeed or fail to handle delayed feedback when spotting anomalies.
Open → 2609.33980v1

Large language models vary in log anomaly detection effectiveness and cost

Towards Understanding LLM-Based Log Anomaly Detection: An Empirical Study of Performance, Efficiency, and Robustness

Abstract: Large language models (LLMs) have demonstrated promising performance in log anomaly detection, yet how their adaptation strategies, architectures, and deployment configurations affect detection effectiveness remains insufficiently understood. To investigate these factors, we conduct a systematic empirical analysis across three public log datasets, examining different adaptation strategies, model architectures, parameter scales, and quantization settings. Our results reveal substantial performance differences across adaptation strategies, while model scaling yields varying detection gains across datasets. We further observe that models with comparable detection accuracy can exhibit markedly different computational costs, and that low-bit quantization largely preserves detection performance in the evaluated configurations. Finally, we examine detection robustness under structural, semantic, and label noise at different perturbation levels. These findings provide empirical insights into the performance, efficiency, and robustness of LLM-based log anomaly detection, highlighting practical considerations beyond conventional accuracy-oriented evaluation.

Fri 25 SeptMachine LearningCryptography and Security
The gist
Detecting unusual errors in computer logs is important but tricky. The authors studied how different ways of using large language AI models affect their ability to find these errors, how much computing power they need, and how well they work when the data is messy. They found that some training methods work better than others, bigger models don’t always help the same way for every dataset, and cheaper model versions still perform well. Their work helps people choose the best model setup for spotting log problems efficiently and reliably.
Open → 2609.31371v1

Enterprise system tool improves IT workflow error handling accuracy

Enterprise Process Control Tower for IT-Led Improvement

Abstract: Enterprise integration traffic in large Enterprise Resource Planning (ERP) systems move through Electronic Data Interchange (EDI) and the Intermediate Document (IDoc), and the operational tools that surround that traffic remain fragmented. Status records are written for a technical audience, exception handling is performed one document at a time, and process health is read manually from long lists. This work proposes an enterprise process control tower that lets an Information Technology (IT) team observe, diagnose, and improve business workflows from a single operational layer. The design links process health observation, semantic translation of technical status text, machine-learning diagnosis of exceptions with model explainability, grouped recovery actions, and key performance indicators inside one governance framework. The proposed framework is evaluated on a synthetic IDoc event dataset of 84,000 records spanning twelve months, of which 15,120 error records are used to train a five-class remediation-routing model that maps each exception to a standard recovery action. A rule-based router that reproduces current production heuristics serves as the primary baseline. The proposed gradient-boosted diagnosis engine reaches a macro-averaged F1 score of 0.883 on the held-out test partition, against 0.742 for the rule-based router, while Shapely-based attributions expose the drivers of each routing decision to operators. Results are derived from synthetic data and are presented as an internal-consistency demonstration rather than real-world validation. The contribution is an integrated tool design that places diagnosis and governance on the same plane as observation.

Sat 19 SeptComputational Engineering, Finance, and Science
The gist
Large business computer systems often have many small messages about errors, but these messages are hard to read and fix quickly because they are technical and scattered. The authors created a tool that shows the overall health of these business workflows in one place, explains the errors in easy-to-understand terms, and suggests fixes automatically using machine learning. This tool was tested using fake data and it correctly matched errors to fix actions much better than the old rule-based system. The work combines watching, diagnosing, and governing business processes together to help IT teams improve efficiency.
Open → 2609.23082v1

Simple statistical features and large language models improve anomaly detection

LLM-Generated Feature Pools for Time Series Anomaly Detection

Abstract: We study how far a simple statistical pipeline can go on univariate time series anomaly detection under a strict selection protocol. The method extracts a small pool of statistics over sliding windows, scores each window with a transductive robust (MAD) model, and selects a feature subset per domain on a held-out tuning split. On TSB-AD-U it reaches $0.529$ per-series VUS-PR, above the best neural ($0.45$) and statistical ($0.44$) entries on the public leaderboard and within $0.06$ of the strongest pretrained foundation model, several of which use more supervision than ours. Ablations locate the cause: across three selection strategies and a hindsight oracle the score moves by $0.031$, and across the aggregation grid by $0.096$, while changing the candidate pool moves it by $0.226$. The candidate pool sets the ceiling; the search over it is second-order. We therefore generate a pool per domain by prompting a multimodal LLM with in-context example windows from that domain. The generated pools match the hand-crafted one under matched selection, and the two cover different domains: selecting over their union improves on the generated pool in all twelve generator-seed pairs and lifts the pipeline to $0.588$, matching the performance of the best entry on the leaderboard.

Fri 18 SeptArtificial Intelligence
The gist
Detecting unusual patterns in time series data can be challenging. This paper shows that using a straightforward statistical method combined with features generated by a large language model can improve detection. The authors create small sets of numeric features from data windows and use a robust scoring method to find anomalies. They found that generating feature sets specific to each domain with a language model helps the detection method perform as well as the best existing models. Combining human-crafted and model-generated features gives even better results.
Open → 2609.21801v1

Locally served AI models improve root cause detection in IT systems

TriCalRAG: A Three-Strategy, Retrieval-Augmented Benchmark for On-Premise LLM-Based Root Cause Analysis in AIOps

Abstract: Cloud-hosted large language models (LLMs) are increasingly used for root cause analysis (RCA) in AIOps pipelines, but they introduce data privacy risk, network latency, and per-query cost that scale poorly with production log volumes. We present TriCalRAG, a benchmark evaluating open-weight LLMs served locally via vLLM on a single high-memory workstation GPU (NVIDIA RTX PRO 6000, 96GB) against a classical LSTM-based log anomaly detector (DeepLog), across four real, publicly available log datasets (BGL, HDFS, Thunderbird, OpenStack). We evaluate two open-weight models (Qwen2.5-14B, Mistral-Small) under three prompting strategies: zero-shot, few-shot, and retrieval-augmented generation (RAG) over a labeled incident history, reporting accuracy, precision/recall, and F1 with bootstrap 95% confidence intervals across 3 random seeds, alongside throughput and VRAM footprint. Our results show that RAG not only improves mean F1 by 0.10-0.27 over zero-shot prompting but, more importantly, substantially stabilizes model calibration: zero-shot prompting drives both models toward near-degenerate behavior (predicting "anomaly" on up to 100% of incidents on some datasets), while RAG keeps predicted-positive rates close to the true class balance in the majority of configurations. Mistral-Small achieves higher macro-averaged F1 than Qwen2.5-14B (0.644 vs. 0.560) but exhibits calibration failures in more configurations (7 vs. 5 of 12), while running at roughly half the throughput - indicating the better model choice depends on whether a deployment prioritizes peak accuracy or predictable behavior across prompting conditions. Ablations show batching scales throughput 41 times on a single card and that 4-bit quantization reduces latency 20% with no measurable accuracy loss. We release our benchmark harness, dataset splits, and evaluation code to support reproducible on-premise AIOps research.

Sun 13 SeptDistributed, Parallel, and Cluster ComputingArtificial IntelligenceCryptography and Security
The gist
Finding problems in big computer systems is important but challenging, especially when using cloud-based AI that can be slow, costly, and risky for private data. The authors tested AI models that run on local powerful computers with three ways of asking questions, including one that looks up past problem records to help the AI. They found this lookup method made the AI more accurate and reliable, avoiding errors that made it say problems existed all the time. Their work helps companies analyze system errors safely and efficiently without relying on cloud services.
Open → 2609.14762v1

Contextual events improve prediction of next process steps

Leveraging contextual events on structure-aware next activity prediction

Abstract: Predictive process monitoring aims at forecasting various aspects of running processes. Among the different tasks, next activity prediction represents the most extensively investigated. However, only a limited number of existing approaches explicitly encode contextual information, i.e., the environmental conditions in which the process is executed, typically modeled through event log attributes or aggregated measures. In this paper, an approach based on the concept of Instance Graphs is introduced. To incorporate contextual process instances, several encoding strategies are proposed and evaluated by measuring their impact on prediction performance. For each encoding strategy, a set of prefix-Instance Graphs is generated and subsequently provided as input to a Graph Neural Network for the classification task. The proposed approach is evaluated on multiple real-world event logs, and the experimental results demonstrate that incorporating contextual process instances benefits prediction performance.

Tue 8 SeptMachine LearningArtificial Intelligence
The gist
Predicting the next step in a process can help businesses plan and react better. But often, existing methods don’t fully use the context around the process, like conditions or other related events. The authors introduce a new way to encode these contexts using graphs that represent process instances and feed them to a neural network. Their tests with real-world data show that including this contextual information helps make better predictions about what will happen next in ongoing processes.
Open → 2609.08622v1