> ## Documentation Index
> Fetch the complete documentation index at: https://cloudinary.com/documentation/llms.txt
> Use this file to discover all available pages before exploring further.

# Why did my usage spike?



A usage spike doesn't necessarily mean you need to upgrade your plan. The right response depends on which metric spiked, since storage behaves differently from transformations and bandwidth, and whether the spike is a one-off event or a sustained trend.

## Identify which metric spiked

If you're on an **Enterprise** or **Pro PAYG** plan, open the [Billing Dashboard](https://console.cloudinary.com/app/settings/billing/dashboard) for a credit breakdown by resource type. On all plans, check the [Usage Reports](https://console.cloudinary.com/app/home/usage-reports) for trend data over the last 30 days.

## Storage spike

Storage reflects your **current total** and is not a rolling calculation. If storage spiked, something was uploaded or generated recently and is still in your account.

Common causes:

* A batch upload of new assets
* Eager transformations being generated for existing assets
* An upload preset or integration configured to generate more derivatives than intended

**What to do:**

1. Review recently uploaded or generated assets in your [Media Library](https://console.cloudinary.com/app/assets)
2. Delete assets or transformation derivatives you no longer need. Storage drops immediately when assets are deleted.
3. Check if any upload presets are generating more eager transformations than intended

> **NOTE**: Because storage is a current snapshot, deleting assets has an immediate effect on your usage. You may not need to upgrade. Resolving the cause of the spike may be enough to bring storage back within your plan limits.

## Transformations or bandwidth spike

Transformations and bandwidth are calculated over a **rolling 30-day window**. A one-off event (a traffic surge, a bulk re-processing job, a misconfigured URL) will naturally age out of the window after 30 days without any action on your part.

Common causes:

* A traffic surge driving more unique transformation requests than usual
* A code change or deployment generating new transformation URLs at scale
* Dynamically calculated transformation parameters producing many slightly different URLs instead of a consistent set (for example, widths that vary by a pixel rather than snapping to standard sizes)
* A missing cache layer causing previously cached transformations to be reprocessed

**What to do:**

1. Check the [Delivery Reports](https://console.cloudinary.com/app/home/delivery-reports). The **Top Transformations** chart shows which specific transformation URLs are driving the most volume. Look for near-duplicate URLs or unexpected entries.
2. If you see original assets being delivered with high bandwidth (entries with no transformation), consider adding `f_auto` and `q_auto` to those delivery URLs to reduce file sizes.
3. If the spike was from a one-off event, monitor your usage over the next few days. As activity from the spike date ages out of the 30-day window, your usage will come down.

## When to consider upgrading

If usage has been consistently high (not a spike) and shows no sign of coming down naturally, upgrading is the right move. Consider upgrading if:

* Your credit usage is consistently at 80% or more of your monthly allocation
* Your usage is growing month-over-month alongside your traffic or content volume
* The spike was caused by legitimate growth, not a configuration error

> **Related topics**:
>
> * [Billing and plans](billing_and_plans)

> * [Upgrading and downgrading your plan](billing_and_plans#managing_your_plan)

> * [Usage and delivery reports](programmable_media_asset_usage_data)

> * [Why is my account disabled?](ts_why_is_my_account_disabled_and_how_can_i_recover_my_disabled_account)
