From Reactive Firefighting to Capacity Planning: How Castrel Forecasts Disk Growth

Storage never stops growing, but very few teams can answer a more useful question than "what is the utilization right now?"

They need to know whether the current trend is sustainable, when a capacity threshold is likely to be reached, and whether a sudden change is normal business growth or an operational event. Without those answers, capacity management becomes reactive: watch a dashboard, wait for a static alert, and then scramble to clean up files or request more capacity.

Capacity planning should work in the opposite direction. It should start with a measured growth baseline, turn that baseline into a forecast, and then connect the forecast to a decision—investigate, expand, or continue monitoring. More importantly, this process should not depend on an engineer remembering to check. The Agent should run it autonomously and continuously. That is the problem Castrel is designed to address.

The real problem: a threshold alert arrives late

Most teams manage disk capacity through periodic manual inspection and static threshold alerts. An engineer queries disk usage across hosts or data centers. When a partition crosses a preset threshold, an alert fires. Someone then logs into the host, searches for large files, and decides—mostly from experience—whether the growth is ordinary business accumulation or something else, such as log or backup buildup.

If more capacity is needed, the next step is often a rough estimate followed by a budget and procurement request. If the problem looks temporary, the response is manual cleanup: expired logs, stale backups, or orphaned files. When the response comes too late, the partition fills up and the business feels it directly through write failures, a hung database, or an incident that needs immediate firefighting.

This model has three structural weaknesses:

• It observes the current state but does not quantify where the trend is heading.
• It cannot reliably distinguish steady growth from a sudden change, so alerts are difficult to prioritize.
• Capacity requests lack a reviewable time series, which makes it harder to justify how much capacity is needed and by when.

As the number of instances grows, manual inspection grows with it. Teams can end up in a loop of "alert → temporary cleanup → alert again" while the risk of a business-impacting outage remains in the background.

The operational question is therefore not just "has capacity crossed the threshold?" It is "given the current trajectory, when will it cross the threshold, and what changed if the trajectory suddenly moves?"

From raw metrics to a growth baseline

In a typical scenario, an operations team wants to compare disk-capacity trends across data centers and identify which sites deserve attention first. Castrel Agent reads the relevant Prometheus-compatible metric directly—for example, disk_capacity_bytes{datacenter="phx1"}—instead of requiring an engineer to pull values from each host manually.

For this run, Castrel used roughly two months of daily samples from 2025-07-01 through 2025-08-30, sampled every 86,400 seconds. It applied a Holt-Winters model with a seven-day seasonal period and generated a 30-day forecast for 2025-09-01 through 2025-09-30 with a 95% prediction interval.

Before going further, several key concepts should be distinguished:

• Capacity: total available disk space in a data center.
• Usage: disk space that is actually occupied.
• Utilization: usage / capacity, representing how full the disks are.
• Prediction interval: the range within which a forecast value is expected to fall, reflecting forecast uncertainty—not forecast accuracy.

The training data for this experiment comes from disk_capacity_bytes—total disk capacity per data center. This means the model forecasts changes in the capacity baseline. Later sections show how to combine capacity forecasts with usage data to derive a complete capacity risk timeline.

The output is not just a number at the end of the month. It includes:

• a forecast trajectory for each data center;
• upper and lower prediction bounds, representing the uncertainty range; and
• actual values over the forecast period, so the forecast can be verified rather than assumed correct.

Forecast validation

A useful forecast evaluation must separate two situations that look similar on a chart but mean different things operationally:

1. Organic growth: capacity changes according to the historical pattern. Forecast error here reflects how well the model captures the growth trend.
2. Baseline change: capacity was deliberately added or removed during the forecast period. This divergence cannot be simply attributed to model prediction capability, because the object being forecast underwent a structural change.

The generated report preserves the daily forecast, prediction bounds, and actual value for every site, making that distinction reviewable.

Forecast accuracy

An important distinction: forecast accuracy and prediction interval are different concepts. A 95% prediction interval describes the range within which future values are expected to fall, reflecting forecast uncertainty. Forecast accuracy measures the deviation between predicted and actual values.

The table below uses month-end values from the report to evaluate forecast accuracy. The percentage is calculated as (actual − forecast) / forecast.

For the three organic-growth sites—phx1, sac0, and yyz1—the mean absolute percentage error (MAPE) is approximately 0.45%, with a maximum absolute error of 1.18%. Within this time window and sample, that indicates the model captured the organic capacity trend well.

The other three sites diverged primarily because the capacity baseline underwent a structural change during the forecast period—disks were added or removed, altering the object being forecast. This divergence cannot be simply attributed to insufficient model prediction capability. Its value is that when the Agent detects actual values significantly departing from the forecast trend, it can prompt operators to investigate further against change records, rather than simply treating it as a forecast failure.

It should be noted that the current validation is based on month-end endpoint values only. For a more comprehensive assessment, daily error analysis over the full forecast period could be added. The current sample size limits the scope of the conclusion, but it is sufficient to establish that forecasts can be evaluated quantitatively, and the evaluation should distinguish organic growth from baseline changes.

From capacity forecast to a capacity risk countdown

A capacity forecast answers "what is the growth trend for the next 30 days," but what operations really cares about is: "at the current rate, when will we enter a capacity risk zone, and how much time do we have to prepare?"

Answering that question requires combining the capacity forecast with usage data to calculate when capacity thresholds will be reached.

Take the phx1 data center as an example. As of 2025-09-30, phx1 shows the following capacity and usage status:

Operations teams typically set two capacity thresholds:

• 80% planning threshold—entering the early-warning zone; capacity evaluation and budget planning should begin.
• 90% risk threshold—entering the urgent risk zone; expansion or cleanup must be executed immediately.

Based on the current utilization and recent growth trend, the Agent calculates:

This means phx1 is not in an urgent risk state, but has approximately 46 days of runway before entering the planning threshold. The operations team can use this window to complete capacity evaluation, budget approval, and hardware procurement. There is an additional ~58-day risk buffer between the 80% planning threshold and the 90% risk threshold—the actual action window between "should start planning" and "must complete expansion." If growth accelerates, these windows shrink accordingly—which is exactly why the Agent needs to continuously monitor and dynamically update forecasts.

The Agent's capacity risk assessment for this site:

phx1 risk rating: Medium

Current utilization 72.0%, estimated to reach the 80% planning threshold in 46 days (~mid-Nov 2025). Recommend initiating capacity evaluation within the next two weeks to complete planning before entering the warning zone. If daily growth consistently exceeds 2,700 TB, the risk window will narrow further, and the Agent will update forecasts and adjust the risk rating in the next inspection cycle.

The forecasting algorithm answers "what is the growth trend." The Agent turns that trend into "how many days remain and what should be done"—the answer operations teams actually need.

What the Agent adds beyond a forecasting algorithm

A forecasting algorithm answers one question:

Given this time series, what is the likely future trajectory?

A standalone Holt-Winters implementation can consume a series and return a forecast and prediction bounds. It does not decide which metrics to query, run the same analysis across multiple data centers, compare results with actual values, investigate divergence, or turn findings into operational recommendations.

More importantly, a forecasting algorithm does not decide when to run. It requires someone to invoke it.

The Agent's core difference is not chaining a forecasting algorithm into a predefined sequence. It is the ability to autonomously understand a problem, acquire information, choose the right analysis, interpret results, and decide what to do next—all oriented around a capacity management goal.

Autonomous analysis and decision-making

In this example, the Agent completed the following—not by following a fixed predefined process, but by autonomously deciding what to do at each step based on the current problem and data:

1. Understand the task. Determine whether the current question is about trends, risk, or planning windows, and decide what data and analysis methods are needed accordingly.
2. Acquire data. Based on what the problem requires, autonomously query the monitoring system for the relevant metrics, time ranges, and data-center dimensions.
3. Analyze per site. Apply forecasting to each data center separately rather than treating the fleet as one undifferentiated series.
4. Validate the forecast. Calculate forecast error, and use prediction bounds to identify whether actual values show significant departures, distinguishing organic growth from baseline changes.
5. Calculate capacity risk. Combine usage trends with total capacity to project each site's threshold-crossing dates and remaining planning windows.
6. Identify high-risk sites. Rank sites by planning window length and flag those requiring immediate attention.
7. Investigate further. When growth rate changes abruptly or actual values significantly depart from the forecast trend, autonomously decide whether more information is needed to analyze the cause.
8. Form a decision. Generate a capacity planning report with risk ratings, threshold dates, planning windows, and action recommendations.

Continuous autonomous inspection

The other key differentiator is that the Agent does not wait for a human trigger—it can autonomously initiate capacity analysis through scheduled inspection.

Scheduled inspection only triggers the Agent. The subsequent analysis is entirely up to the Agent to decide:

flowchart TD
    A["Scheduled inspection triggers (daily/weekly)"] --> B["Agent understands current capacity state"]
    B --> C["Autonomously decides which monitoring data to acquire"]
    C --> D["Autonomously decides which sites need further analysis"]
    D --> E["Invokes forecasting capabilities when needed"]
    E --> F["Combines forecast results with existing knowledge to assess risk"]
    F --> G["Autonomously decides whether further investigation is needed"]
    G --> H["Forms capacity planning recommendations"]
    H --> I{"Risk level"}
    I -->|"High risk"| J["Proactively notifies operations team"]
    I -->|"Low risk"| K["Logs and continues monitoring"]
    J --> L["Next cycle triggers again"]
    K --> L
    L --> A

This means that even if no one asks "is disk capacity still sufficient," the Agent periodically discovers issues, updates forecasts, assesses risk, and proactively pushes notifications when necessary. If the previous cycle estimated a site would reach the planning threshold in 45 days, but this cycle finds that growth has accelerated and the estimate has shortened to 27 days, the Agent automatically raises the risk rating and recommends starting expansion preparations earlier.

This changes the starting point for an operations conversation. Instead of waiting for "disk full" and then asking what happened, the team can discuss a measured trajectory, an expected planning date, the uncertainty around that date, and the evidence behind the assessment. And this is not a one-time analysis—it is a continuously running, continuously updating loop.

This is the fundamental difference between the Agent and a forecasting algorithm:

• Forecasting algorithm: "Give me a time series and I will tell you the future trend."
• Agent: "I will understand the current situation, get the data I need, decide whether forecasting is required, interpret the results, assess risk, provide recommendations, and keep repeating this process—without anyone needing to remember to ask."

From a forecast curve to a capacity planning decision

1. Identify capacity growth trends from historical monitoring data. The Agent can directly read Prometheus metrics and collect historical capacity data across multiple data centers.
2. Produce quantifiable forecasts for future capacity. On the three organic-growth sites, the mean absolute percentage error (MAPE) was approximately 0.45%, with a maximum absolute error of 1.18%.
3. Detect anomalous departures in capacity trends. When actual growth significantly departs from the forecast trend, the Agent can analyze further using prediction bounds and related information, providing a basis for subsequent investigation.
4. Calculate capacity threshold dates and remaining planning windows. By combining usage trends with total capacity, the Agent projects when each site will reach 80% and 90% thresholds, with estimated dates and remaining days.
5. Identify high-risk data centers and provide capacity planning recommendations. Including risk ratings, planning windows, and specific action items.
6. The Agent autonomously completes data collection, analysis, forecasting, risk assessment, and report generation. Not by following a fixed process, but by autonomously deciding what to do next based on the current problem and data.
7. The Agent runs continuously through scheduled inspections. Each cycle autonomously updates forecasts and reassesses risk, without waiting for a human trigger.

The value of this approach is not just a line on a forecast chart. It changes how capacity management works:

From passively waiting for capacity alerts to an Agent that proactively discovers capacity risks and provides quantifiable planning windows in advance.

The forecasting algorithm provides the statistical growth estimate. The Agent embeds that forecasting capability into a capacity management process that can autonomously understand, analyze, decide, and run continuously—transforming a one-time model call into a system that runs on its own, updates on its own, and alerts on its own.