DevOps & Cloud · Capacity forecasting
CapacityRunway
Know the day it fills up.
Every disk, volume, database, connection pool and quota, ranked by the date it runs out, forecast from the Prometheus history you already have.
$ capacity-runway check --prometheus http://prometheus:9090
7 resources; 3 critical, 1 warning, 1 within the horizon
now 92% inodes ci-agent-3 /
3.1d 82% pvc kafka data-kafka-0 growth speeding up 6x
15d 73% pg-connections db-1:9187
40d 69% disk db-1 /var/lib/postgresql +2.6 GiB/day
The problem
Disk-full and too-many-connections outages are visible in the metrics weeks ahead, but a fixed 85% alert fires either too late or every night. Nobody looks at 200 graphs to see which one is trending towards the edge.
What it does
Reads Prometheus directly: disks and inodes, Kubernetes volumes, memory, conntrack, file descriptors, Postgres and MySQL connections, namespace quotas
Forecasts on each day's peak with a robust trend, so one spike or one cleanup doesn't move the date
Ignores log rotation and nightly cleanups, and notices when growth suddenly speeds up
One list across every resource: days left, the date, current use and growth per day
Any other resource through your own query and limit, or a CSV from CloudWatch, Datadog or a spreadsheet
Writes Prometheus alert rules for the same forecast, so it keeps watching
Weekly CI report that fails when something is critical
How it works
- Point it at Prometheus, read-only
- Get the list of resources that fill up, with dates
- Plan the fixes and install the alert rules
Works with
Runs in your CI
# Weekly capacity report
capacity-runway check --prometheus $PROM --format md --out runway.md --fail-on critical
Your data
- Read-only queries; nothing is changed.
- No agent to install.
- Runs on your laptop or in CI.
Who it's for
Questions
Doesn't predict_linear already do this?
It fits raw samples, so nightly cleanups and busy hours cause false alarms. CapacityRunway fits daily peaks robustly, spots acceleration and ranks everything in one list, then writes predict_linear rules for ongoing alerts.
How much history does it need?
A few days works; two weeks or more gives steadier dates.
Related
Often used with CapacityRunway
BlastRadar
Change impact analysisKnow what a change will touch. Before a release, see every service a change can affect and the line of code that links it. After the release, confirm those services are still healthy.
$300–600 (₹10,000–20,000 in India)View product → DevOps & CloudSLOStudio
SLOs and error budgetsReliability you can measure. Define each SLO in a few lines and get correct burn-rate alerts, an error budget everyone understands, and a release gate, on the monitoring you already run.
$1,500–3,000 (₹40,000–80,000 in India)View product → DevOps & CloudTestScope
Test impact selectionRun the tests that matter. Every pull request runs the tests its change can affect, each with a stated reason, and the full suite whenever a change is too broad to trust.
$1,000–2,500 (₹25,000–60,000 in India)View product →See CapacityRunway on your own data
A 30-minute call. We run the product on your export, repository or document and walk you through the results.