- Docs
- How-to guides
- Investigate a cost spike
How-to guides
Investigate a cost spike
Find what jumped and why, using the Cost Explorer's What Changed waterfall and Top Drivers chart.
Last updated: 2026-05-21
On this page
A cost spike has two questions behind it: what moved, and why. The Cost Explorer is built around that split. What Changed answers the first; Top Drivers and Inspect answer the second.
This guide assumes you noticed something off — either a budget alert fired, the dashboard Projected month-end jumped, or someone asked. If you're just browsing, the Find your top cost drivers how-to is a better starting point.
Step 1: Bound the spike in time
Open the Cost explorer. The default range is the current month — usually too wide for spike investigation. Tighten it:
- If a budget alert prompted you, set the range to Last 7 days.
- If the dashboard is showing a high projection, look at Last 14 days — long enough to see the trend, short enough to spot a recent step change.
- Use a custom range when you have a date in mind (a deployment, an incident).
The granularity selector auto-picks an appropriate bucket (hourly, six-hourly, daily). Leave it on auto unless the chart is too noisy.
Step 2: Use What Changed to find the delta
Switch to the What Changed view. The waterfall chart shows period-over-period change: bars go up for cost increases and down for decreases. The order matters — the bars are sorted by delta size, so the biggest movers are first.
What you're looking for:
- One tall green bar dominating the others. Usually means a single resource was added or scaled up. Click it to see which.
- Several small green bars across one type (e.g. four new volumes). Often a deployment that provisioned multiple resources at once.
- A large red bar matched by a larger green bar. A migration — a resource was deleted but replaced by something more expensive. Worth confirming the replacement is intentional.
Click any bar to open the Inspect drawer. It shows the resource's hourly cost timeline, its current monthly cost, and the underlying events (creation, type change, deletion).
Step 3: Confirm with Top Drivers
Switch to Top Drivers. Group by resource type first, then by resource.
The resource-type view tells you whether the spike is broad (lots of types up) or narrow (one type up). A narrow spike is easier to act on. A broad spike often signals load increase across the board — real, but harder to "fix".
Group by resource to see individual offenders. This view is more useful when the type view shows one type dominating; switching to per-resource within that type names the specific server, volume, or load balancer.
Step 4: Decide what to do
You usually land in one of three places:
- Intentional and known. Someone deployed something and forgot to mention it. Document it, set a budget if the new spend is significant, and move on.
- Intentional but mispriced. You meant to add capacity but didn't realise the cost. Check Recommendations — if rightsizing already flagged it, follow the suggestion. If not, consider whether a smaller server type or fewer instances would meet the actual load.
- Unintentional. A test environment left running, a snapshot loop, an unattached volume from a failed migration. Stop or delete it. Open the Resources page and filter to the type for a quick audit.
If the spike came from a single resource, save the link to the Inspect drawer in your post-mortem — the URL is shareable and pins the date range.
Common patterns
A few patterns repeat enough to call out:
- Volume costs climbing while server costs are flat. Volumes survive their parent server. Run the Handle unattached volumes how-to.
- Floating IP charges out of nowhere. Floating IPs not attached to a running server are billed at a flat rate. CloudTally flags these in the waste view.
- Snapshot creep. Automated backups can accumulate. Look at the Cost by type chart in the dashboard — if Snapshot is climbing month over month, your rotation policy may not be deleting old ones.
When the spike isn't visible
If you can't see the spike in What Changed, two things to check:
- Are you looking at the right project? If you have multiple Hetzner connections, the explorer aggregates them by default. Filter to the suspect project.
- Is the data stale? The header sync indicator shows when the last sync ran. Trigger an on-demand sync if you need fresh data right now (Pro feature; Free syncs hourly).