Everything that costs money to run on dply is metered: traffic, builds, container compute, databases and every other resource. Usage is billed at the rates on Plans & pricing, on top of your plan fee. This page explains how each meter is measured and where to watch it.
How metering works
- dply collects usage from Cloudflare and from its own database and cache clusters, most of it every hour.
- Usage is added up per organization for the current billing period, which starts on your subscription's renewal date.
- At the end of the period, the total for each category is added to your renewal invoice as a usage line. See Invoices & taxes.
Preview deployments are metered exactly like production. They don't count toward the fair-use limit on apps, but their builds, traffic and compute count.
Sites that run on your own Cloudflare account aren't metered by dply. Cloudflare bills you for them directly.
Meters
| Meter | How it's measured | Collected | Invoice line |
|---|---|---|---|
| Requests | Every request your sites' Workers answer, including cache hits | Hourly, then again the next day | Delivery (requests, bandwidth, site storage) |
| Bandwidth | Bytes delivered to visitors | Hourly, then again the next day | Delivery (requests, bandwidth, site storage) |
| Site storage | The size of each site's published build output at its peak in the period, added up across sites | Hourly, then again the next day | Delivery (requests, bandwidth, site storage) |
| Site storage writes and reads | Writes (publishing a deploy) and reads (cache misses) against your sites' storage | Hourly, then again the next day | Delivery (requests, bandwidth, site storage) |
| Build time | Time in the build container, billed per second past the plan's included minutes (300 Starter, 1,000 Pro, 3,000 Team) | When each build finishes | Build time |
| Container apps and queue workers | vCPU-seconds, memory and disk for every second an instance runs, and bytes sent out | Hourly, then again the next day for late samples | Apps and workers (compute) |
| Postgres, MySQL and MongoDB | Compute-unit seconds while the database is awake, and disk size for every hour | Hourly | Databases |
| Valkey | Seconds the store is awake, priced by its size and capped at the size's monthly maximum | Hourly | Valkey |
| Key-value | Reads; writes, deletes and lists; stored bytes per store | Hourly, then again the next day | SQL, queues and key-value |
| Edge SQL (D1) | Rows read, rows written, stored bytes | Hourly, then again the next day | SQL, queues and key-value |
| Queues | Queue operations | Hourly, then again the next day | SQL, queues and key-value |
| Realtime | Connection-minutes and messages (publishes; deliveries are free) | Hourly | Realtime |
| Workers CPU | CPU time used by your SSR, middleware and container front Workers | Hourly, then again the next day | Workers CPU, Durable Objects, object storage and images |
| Durable Objects | Requests, duration, rows read and written, stored bytes, for State and container apps | Hourly, then again the next day | Workers CPU, Durable Objects, object storage and images |
| Object storage buckets | Stored bytes, writes and reads on buckets you add as a resource | Hourly, then again the next day | Workers CPU, Durable Objects, object storage and images |
| Image transformations | Unique transformations | Hourly, then again the next day | Workers CPU, Durable Objects, object storage and images |
| AI | Neurons, from each call's model and tokens | As each call finishes | AI, browser rendering and vector search |
| Browser rendering | Browser time, per second | As each session closes | AI, browser rendering and vector search |
| Vector search | Queried dimensions per query; stored dimensions per index | Queries as they run; storage hourly | AI, browser rendering and vector search |
Collection times are in UTC. The next-day run picks up samples Cloudflare reports late, so today's figures can rise slightly after the day ends. When your plan renews, the period's last day is collected again before its usage is invoiced.
Every meter above is billed from the first unit. No plan includes usage, and there's no per-meter allowance.
Where to see usage
Billing page
Your organization's Billing page shows, for the current period:
- Usage this period — what your usage lines come to today, at customer price.
- Estimated charge — usage this period, projected to the end of the billing period.
The page also shows the billing period's dates.
Projects usage
The Usage page, reached from Projects on your dashboard, shows requests, bandwidth, storage and an estimated cost for each project side by side.
Note
The Usage page counts the calendar month, while invoices count your billing period. If your subscription renews mid-month, the two cover different dates.
A single project
Each project's observability section has Billing & usage. It opens with what the project has used this billing period, billed on top of your plan fee, and lists one row per cost line. Monthly quota and Daily activity expand for the soft cap and daily charts. Resource sheets for key-value and object storage have their own Usage tab.
The API
GET /api/v1/billing and GET /api/v1/billing/breakdown return the same figures as the Billing page, and GET /api/v1/billing/invoices lists invoices. Each needs a token with the billing.read ability. See HTTP API.
Keep usage down
- Let container apps, databases and Valkey sleep when idle. See Scaling & sleep.
- Cache responses at the edge, so requests don't reach your app or storage. See Caching.
- Delete preview deployments you no longer need.
- Set a usage alert, so you hear about growth before the invoice. See Spending caps & alerts.