# Understand storage usage and capacity

> Understand pooled storage, pending bytes, request and transfer metrics, upload refusals, and plan changes without losing data.

Source: https://docs.fortly.com/files/usage-and-capacity

Stored capacity answers “how much can this account keep?” Request and transfer metrics answer “how is this bucket being used?” They are separate measurements. Reading a file does not create another stored copy.

> **Note:**
>
> Private bucket metrics require an enabled installation. Plan estimates do not purchase capacity. Fortly does not currently connect payment collection, a prepaid wallet or automatic usage invoicing.

## Read the right meter

| Figure | Scope | What it tells you |
|---|---|---|
| Bucket size and object count | The selected bucket | Committed objects currently visible in that bucket |
| Pending bytes | The selected bucket | Unfinished work and cleanup attributed to that resource |
| Account storage | All projects owned by the account | Committed and reserved bytes against the saved plan and Storage Packs |
| Activity this month | The selected bucket, for requests started in the current UTC calendar month | Authorized read/write attempts and HTTP body bytes processed by Fortly |
| Billing plan estimate | A proposed plan and capacity configuration | A comparison only; it does not change an entitlement or charge a card |

The bucket header can be smaller than the account meter. Other projects, public files, multipart uploads and pending cleanup are part of the shared pool. **Refresh files** reloads the current folder and capacity after SDK writes. **Refresh usage** reloads the monthly request and transfer totals.

## What consumes object-storage capacity

Private objects, public Project files and Worker R2 buckets all use the account's object-storage allowance. Incomplete multipart bytes, active upload reservations, uncertain writes and superseded objects waiting for deletion also occupy capacity. Starting another project or creating another bucket does not provide a fresh allowance.

PostgreSQL has its own pooled database allowance. Key-value entries, deployment artifacts and platform backups do not silently consume this file-storage pool. Platform metering records are not customer object bytes. Keeping two distinct objects with identical contents still stores two copies; downloading one of them stores nothing new.

An application release does not clear these files. PostgreSQL point-in-time recovery does not rewind them. Permanent bucket deletion is separate from database recovery and has no recovery window.

## Why an upload can be refused

Fortly reserves capacity before accepting a private upload body or writing it upstream. Every participating writer checks the same durable account pool, so simultaneous console, S3 and Worker writes cannot each spend the same remaining capacity.

For example, an account with a 10 GB allowance, 8 GB stored and 1 GB already reserved has 1 GB available for another reservation. A 2 GB multipart upload cannot reserve the missing space just because the selected bucket is empty. Each part still has to satisfy the supported part size and the shared account cap.

A replacement temporarily needs room for the incoming object while the previous object stays readable. If a 20 MB file is replaced by a 15 MB file, admission still needs room for the 15 MB incoming copy. Once the old 20 MB is physically removed, its capacity is released. A smaller replacement does not bypass admission.

When an upload is refused, no background purchase or automatic overage pack is created. Free space, finish or abort incomplete uploads, wait for cleanup, or arrange a larger saved entitlement. Authorized downloads and deletions remain available when capacity is full.

## Understand pending cleanup

Deleting an object removes it from listings before the backing bytes necessarily disappear. Capacity remains counted until deletion is confirmed. Interrupted uploads and uncertain provider operations keep their reservations until durable cleanup reconciles them. A process restart does not reset these counters.

A file that has disappeared from **Files** may therefore still contribute temporarily to the account meter. Refresh after cleanup. If pending usage persists or the console says reconciliation is required, contact support with the bucket identity and request ID. Do not resend a large upload repeatedly to force the meter to change.

## Change a plan without stranding data

An accepted upgrade raises storage admission capacity when the new tier and packs are saved. The console's comparison remains an estimate: choosing a different tier there does not update your live plan.

A plan reduction or Storage Pack removal cannot take effect when the requested capacity is below stored plus reserved bytes. The request is rejected and the current tier and packs remain unchanged. Free space and wait for cleanup, or explicitly retain enough paid Storage Packs on the smaller base plan. Nothing is automatically deleted, and Fortly does not silently add a pack.

The reduction uses the same account lock as uploads. A new upload cannot race the plan change and slip past the lower allowance. If inventory is not reconciled, reducing capacity is blocked until the figures are trustworthy. See [account limits](https://docs.fortly.com/account/limits) for the plan-estimate workflow.

## Interpret read, write and traffic totals

**Read requests** include supported authorized S3 discovery, listing, metadata and object reads. **Write requests** include supported mutations, such as PUT, copy, deletion and multipart operations. Console file listings, uploads and deletions contribute too. Creating keys or editing settings is not an S3 object request.

Retries count separately. A multipart upload can contain several write requests even though it produces one final object. An authorized request that fails validation or quota admission can contribute a failed attempt. Rejected authentication and cross-bucket probes are not attributed to the bucket they attempted to target.

**Data received** and **Data sent** measure HTTP body bytes processed by Fortly. Listing and error bodies count; headers, TLS overhead and provider-internal copy traffic are not invented as customer object transfer. HEAD sends no object body. A four-byte range contributes four response-body bytes rather than the whole object's size.

Records persist across restarts. A request is complete when its declared response length has been handed to the transport, or an unknown-length response reaches EOF. Interrupted streams retain their measured progress. Transport handoff is not proof of receipt by a remote client. These figures are not automatically invoiced, and the UTC month is not a connected payment-provider billing cycle.

[CDN delivery](https://docs.fortly.com/files/cdn#track-requests-and-delivery-bytes) has its own durable request/body-byte ledger, hit/miss/bypass activity and explicit shared account/month budgets. Edge hits reserve capacity too; lost receipts stay pending. Cached copies do not charge the stored object a second time. The S3/console counters above exclude CDN requests; public Project files also have a separate delivery model. Do not interpret one meter as all application traffic.

## Resolve a storage refusal

| Symptom | What to check | Next step |
|---|---|---|
| Shared storage allowance exceeded | Stored plus reserved bytes across the account | Remove files or retain/add sufficient capacity; allow cleanup to settle |
| Storage usage needs reconciliation | Provider inventory does not agree with the ledger | Preserve reads/deletes; contact support if the state persists |
| Four uploads already in progress | Account-wide transfer reservations | Finish current transfers, then retry with backoff |
| Read-only access | The key or connection permission | Use a separate authorized write credential; do not expose a management token |
| S3 signature rejected | Endpoint, region, path style, exact URL/headers and key state | Match the connection settings and avoid rewriting signed URLs |
| Browser request blocked | Exact origin, method and headers as well as signature | Review a complete CORS rule; CORS alone does not authorize access |
| API returns disabled/unavailable | Installation's bucket availability | Use the enabled account workflow; do not move private content into public files |

The [bucket guide](https://docs.fortly.com/files/private-buckets#compatibility) lists supported operations and limits. For request formats and error responses, use the [control API](https://docs.fortly.com/api/buckets). An [approved agent](https://docs.fortly.com/agents/mcp) can inspect aggregate usage without receiving object names, contents or secrets.