Understand storage 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.

Read the right meter

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 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 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

The bucket guide lists supported operations and limits. For request formats and error responses, use the control API. An approved agent can inspect aggregate usage without receiving object names, contents or secrets.