ChronoGraph: Graph-Structured Forecasting Benchmark

• ChronoGraph is a benchmark that combines multivariate time series with an explicit machine-readable dependency graph and expert-curated anomaly labels.
• It models production microservices with 708 services, 8005 time steps, and both dynamic node and edge metrics capturing inter-service communication.
• The benchmark supports forecasting, anomaly detection, and incident-aware robustness analysis, highlighting limitations of topology-agnostic methods.

ChronoGraph is a dataset and benchmark for graph-structured multivariate time-series forecasting and anomaly evaluation in production microservice systems. It models a real deployed software platform as a directed service dependency graph in which each service emits multiple operational metrics over time and disturbances can propagate along service interactions. Its defining combination is threefold: multivariate time series, an explicit machine-readable dependency graph, and incident-aligned anomaly labels derived from real production incidents. In the benchmark formulation, the primary task is forecasting future values of service-level signals, while expert-annotated incident windows support anomaly detection and incident-aware robustness analysis (Lutu et al., 4 Sep 2025).

1. Problem setting and benchmark identity

ChronoGraph is designed for the operational setting of modern large-scale microservice architectures, where forecasting service behavior is relevant to alerting, autoscaling, and capacity planning, but service metrics are not independent. Hundreds of loosely coupled services call one another, share resources, and can fail in ways that spread across dependencies. The benchmark therefore treats production telemetry not as a collection of isolated sequences, but as graph-structured multivariate time series over a service dependency network.

A central point of the benchmark is that the graph structure is explicit rather than latent. Directed edges encode dependencies between services and are induced by observed communication. This differs from benchmarks in which relations are implicit, unavailable in machine-readable form, or represented only by process diagrams. The anomaly labels are likewise operational rather than synthetic: they are expert-curated incident windows derived from internal incident reports and attached to specific services and timestamps.

This makes ChronoGraph a benchmark rather than a forecasting architecture. The paper strongly motivates graph-aware learning, but the object introduced is the dataset and evaluation protocol itself, not a new topology-aware model. A plausible implication is that ChronoGraph is intended to expose the gap between realistic microservice observability data and the capabilities of current topology-agnostic baselines (Lutu et al., 4 Sep 2025).

2. Graph structure, telemetry, and temporal representation

ChronoGraph is built from six months of operational telemetry collected from a production microservice platform run by a large enterprise. The graph is described as

$G=(V,E),$

where nodes $V$ are microservices and directed edges $E$ represent observed inter-service communication and service dependencies.

Each node carries a 5-dimensional multivariate time series of system-level metrics. The five node variables are CPU usage, memory usage, memory working set, incoming network traffic rate, and outgoing network traffic rate. These measurements are collected per container and then aggregated to the service level by taking the mean across containers. The node data are naturally represented as

$\mathbf{X}\in\mathbb{R}^{T\times |V|\times F},$

with $T=8005$ timestamps, $|V|=708$ services, and $F=5$ node-level variables.

Beyond node telemetry, ChronoGraph includes 3-dimensional time series on edges. For each interacting pair, the edge time series contains number of requests, return codes, and latency. Accordingly, the benchmark is not limited to a static graph with node signals; it also includes dynamic relational information.

The telemetry is sampled at a fixed 30-minute interval. After cleaning and alignment, each service has 8005 time steps. The paper provides the following concrete dataset statistics: 708 services or nodes, 8005 time steps per service, 5 node variables, 3 edge variables, and six months of telemetry. It does not provide the exact number of edges, the total number of edge time-series instances, or the number of separate graph snapshots or graph instances.

The topology appears to be an explicit directed dependency graph derived from observed communication, with time-varying signals on nodes and edges. However, the paper does not explicitly clarify whether the adjacency itself changes over time or whether a fixed graph is used after aggregation. The safest reading is therefore that node and edge attributes are time-varying, while the temporal status of the edge set $E$ itself is not explicitly specified (Lutu et al., 4 Sep 2025).

Component	Specification
Nodes	708 services
Node variables	5 metrics
Edge variables	3 metrics
Time steps	8005
Sampling interval	30 minutes
Duration	6 months

3. Forecasting, anomaly detection, and incident-aware evaluation

ChronoGraph supports at least two major tasks: multivariate forecasting at the service level, and anomaly detection using incident windows as ground truth. It also supports incident-aware robustness analysis, because incident labels allow evaluation specifically around disruption periods.

The primary forecasting task is to forecast future values of service-level metrics for each node. The benchmark uses a 60/40 train–test split, with forecasting evaluated on the full 3202-step test window and on the first 500 test steps. The reported forecasting metrics are MAE, MSE, and MASE. The paper does not define a canonical forecasting objective in equation form, but the supported prediction problem is naturally of the form

$$\text{predict future values } \mathbf{X}_{t+1:t+H} \text{ from past observations } \mathbf{X}_{t-L+1:t}.$$

For anomaly detection, ChronoGraph uses incident windows as labels. The setup is largely unsupervised: anomaly scores are derived from forecast residuals or from reconstruction and outlier scores. For forecasting-based anomaly detection, the paper computes z-scores of residuals from forecasting models and evaluates these with an anomaly detection protocol from prior work, although the exact z-score formula is not given.

The paper emphasizes that conventional pointwise precision, recall, and $F1$ can be misleading for segment anomalies. Its primary anomaly metrics are therefore $V$0-AUC and $V$1-AUC. It also reports false positive rate, false negative rate, and conventional $V$2. The stated rationale is that ordinary point-adjusted scoring can inflate performance by marking a whole anomaly segment correct if only one point is detected.

A notable feature of the benchmark is that incident windows are expert-curated but sparse and not exhaustive. The labeling pipeline is described explicitly: human-written incident entries are collected, parsed to extract affected services and timestamps, and then mapped to fixed-length windows centered on the reported time. This produces 17 labeled anomaly segments associated with specific services. The intended use is both benchmarking anomaly detection methods and assessing the robustness of forecasting methods during operational disruptions. A crucial interpretive caveat is that detections outside the labeled incident set may still correspond to operationally useful early-warning signals or self-resolving problems, even though they are scored as false positives (Lutu et al., 4 Sep 2025).

4. Baselines and empirical findings

The baseline study spans forecasting models, pretrained time-series foundation models, and standard anomaly detectors. The forecasting baselines are Prophet, Chronos-Bolt Base, and TabPFN-TS. Prophet is trained as a separate model for each dimension. Chronos-Bolt Base uses a rolling prediction strategy that forecasts the first 64 time steps, appends them to the context, forecasts the next 64, and repeats until the horizon is covered. TabPFN-TS is trained jointly on the entire multivariate time series, leveraging cross-series dependencies.

On the full 3202-step test window, average forecasting performance over all services is reported as follows: Prophet has MAE $V$3, MSE $V$4, and MASE $V$5; Chronos has MAE $V$6, MSE $V$7, and MASE $V$8; TabPFN-TS has MAE $V$9, MSE $E$0, and MASE $E$1. The stated trend is that Prophet and TabPFN-TS are comparable in MAE on long horizons, with TabPFN-TS best in MASE, while Chronos is worst overall.

On the shorter horizon of the first 500 test steps, Prophet has MAE $E$2, MSE $E$3, and MASE $E$4; Chronos has MAE $E$5, MSE $E$6, and MASE $E$7; TabPFN-TS has MAE $E$8, MSE $E$9, and MASE $\mathbf{X}\in\mathbb{R}^{T\times |V|\times F},$0. The key pattern is that Chronos performs best on short horizons, but experiences the largest drop when moving to long-horizon evaluation. TabPFN-TS is described as the most stable across short and long horizons.

Anomaly detection performance is reported as modest across all tested methods. Prophet is the strongest individual anomaly detector by $\mathbf{X}\in\mathbb{R}^{T\times |V|\times F},$1 and $\mathbf{X}\in\mathbb{R}^{T\times |V|\times F},$2, with $\mathbf{X}\in\mathbb{R}^{T\times |V|\times F},$3 and $\mathbf{X}\in\mathbb{R}^{T\times |V|\times F},$4, but it has a false negative rate of $\mathbf{X}\in\mathbb{R}^{T\times |V|\times F},$5. Isolation Forest and OC-SVM detect more anomalies but incur much higher false positive rates. Autoencoder, TabPFN-TS, and Chronos perform poorly overall in anomaly detection. The ensemble combining Prophet, Isolation Forest, and Autoencoder yields the lowest false positive rate, $\mathbf{X}\in\mathbb{R}^{T\times |V|\times F},$6, but still misses most labeled incidents.

The broader empirical conclusion is that current approaches are reasonably effective for short-term forecasting but lack stability for long-range prediction in this domain, and that topology-agnostic methods struggle for both forecasting robustness and anomaly detection. The paper does not empirically demonstrate that graph-aware models outperform non-graph baselines on ChronoGraph, because such baselines are not included. This suggests that the benchmark’s most important immediate role is diagnostic: it exposes a realistic failure regime for methods that ignore explicit service topology (Lutu et al., 4 Sep 2025).

5. Position relative to prior benchmarks

ChronoGraph is positioned against two benchmark families. The first comprises traffic and air-quality datasets, which often provide explicit graph or spatial structure but are frequently univariate and generally lack incident annotations. The second comprises industrial control system datasets such as SWaT and WADI, which include multivariate signals and anomaly labels but do not provide a true adjacency matrix representing machine-readable graph topology.

The benchmark’s central comparative claim is therefore not merely scale or realism in isolation, but the simultaneous presence of three properties: multivariate time series, an explicit machine-readable dependency graph, and anomaly labels aligned with real incidents. In the paper’s framing, this combination is what existing popular benchmarks do not provide in a single operationally meaningful dataset.

The domain shift is also substantive. ChronoGraph comes from observability data in production microservices rather than transport networks, environmental sensors, or industrial processes. Dependencies reflect service-to-service communication, node features encode service-level telemetry, and anomaly labels are derived from internal incident reports. This setting foregrounds propagation across software dependencies rather than across roads, air basins, or engineered physical process stages. A plausible implication is that ChronoGraph is particularly suited to research on disturbance propagation and topology-aware robustness under software-system distribution shift, because both the topology and the incidents are operational rather than synthetic (Lutu et al., 4 Sep 2025).

6. Significance, limitations, and reproducibility

ChronoGraph matters because it exposes a realistic and underrepresented problem setting: observability data from production microservices in which both temporal dynamics and dependency structure are critical. For microservice observability, it supports research on proactive capacity planning, alerting, service health forecasting, and modeling incident spread across dependencies. For graph time-series forecasting, it provides a testbed where graph structure corresponds to a real dependency network. For anomaly detection, it enables evaluation against real incident windows rather than synthetic perturbations.

The paper explicitly acknowledges several limitations. The anomaly labels are sparse and non-exhaustive: only 17 labeled anomaly segments are provided, and many true anomalies may be unlabeled. Some detections scored as false positives may in fact be useful early-warning signals. The dataset comes from one enterprise production platform, so domain biases tied to that specific environment are plausible. The paper strongly motivates topology-aware methods but does not benchmark explicit graph neural forecasting or graph-based anomaly detection methods on ChronoGraph itself.

Reproducibility details are partial but substantial. The paper specifies the 30-minute sampling interval, 708 services, 8005 time steps, 5 node metrics, 3 edge features, the 60/40 train–test split, evaluation on the full 3202-step test window and the first 500 test steps, the 64-step rolling forecast schedule for Chronos, per-dimension Prophet fitting, joint TabPFN-TS training on the entire multivariate time series, and z-scored residuals for forecasting-based anomaly scoring. It does not specify license terms, exact access conditions, exact preprocessing code beyond high-level alignment and cleaning, exact edge count, exact split boundaries by date, standardized context-window length $\mathbf{X}\in\mathbb{R}^{T\times |V|\times F},$7 or forecasting horizon $\mathbf{X}\in\mathbb{R}^{T\times |V|\times F},$8, or complete hyperparameter settings. The manuscript also states that dataset and code are publicly available at a placeholder URL, indicating intended public release but incomplete publication metadata at the manuscript stage.

ChronoGraph’s longer-term significance lies in the research agenda it opens rather than in the baseline results alone. The benchmark naturally enables graph neural forecasting over service dependency graphs, node-edge co-modeling using both service metrics and communication features, incident propagation modeling, topology-aware anomaly detection, robust forecasting under distribution shift, root-cause localization, and graph-based explanation. The paper’s overarching conclusion is that topology-agnostic methods are insufficient for this domain; ChronoGraph is introduced as the benchmark needed to make that insufficiency empirically visible and to support subsequent graph-aware work (Lutu et al., 4 Sep 2025).