cloudflare-caution

Original：🇨🇳 Chinese

Translated

Choose a cost-effective Cloudflare architecture using Workers, Static Assets, KV, D1, R2, Durable Objects, Queues, and Workers Logs while avoiding designs that lead to ballooning bills. Use this when designing Cloudflare deployments, adding Workers or bindings, deciding how to distribute pages and data, or writing loops and retry logic.

15installs

Sourcemasseater/skills

Added on2026-10-29

NPX Install

npx skill4agent add masseater/skills cloudflare-caution

SKILL.md Content (Chinese)

View Translation Comparison →

cloudflare-caution

Rules for designing on Cloudflare so that bills do not balloon.

Do not run processes that produce the same result on every request
Add safeguards against runaway execution in both code and configuration
Estimate costs based on billable units and verify them against production usage

Why this skill is needed and the desired outcome

This skill is needed because Cloudflare bills for fine-grained usage units such as requests, rows, operations, and log events, with no spending cap. Each unit is inexpensive on its own, so the cost is easy to overlook while building. However, a design that runs SSR, APIs, or a database for every view makes costs grow proportionally with traffic. If there is a bug in a loop or retry logic, every iteration becomes billable. Budget alerts notify you, but they do not stop spending.

The desired outcome of this skill is for the cost per visit to be determined at the design stage. Even if bugs or bots exceed expectations, the code and configuration should stop the activity before it becomes billable.

Unit prices and how billing works

Materializing reusable results

Recreating the same result for every view causes Worker invocations, CPU time, and database rows to scale with traffic and become billable. Precompute and distribute anything that can be precomputed.

For public pages that are identical for everyone, prerender them at build time and serve them as Static Assets. Requests for Static Assets do not invoke a Worker and are therefore not charged
Serve public static sites from an asset-only Worker with no Worker code. Do not make delivery through R2 or a Worker the primary path for public pages
“Fits within the free tier” is not a reason to serve public pages through a billable path. A sudden increase in traffic will exceed the free allowance
Using a CSP nonce requires generating HTML for every request. For public static pages, do not rely on nonces. Move inline scripts to external files and apply a shared CSP to all pages through
```
_headers
```
. Listing per-page hashes in
```
_headers
```
will eventually break because of the rule limit of 100
Limit
```
assets.run_worker_first
```
to authentication and API paths. Applying it globally makes requests for Static Assets subject to Worker billing as well
Render only the parts that change per viewer dynamically. Do not render the entire page dynamically
Store dynamic data in the CDN cache, Cache API, or KV according to how frequently it changes. Do not call D1 or an external API on every request
Do not refetch data on the client while it remains unchanged. If using TanStack Query, configure
```
staleTime
```

Safeguards against runaway execution

Because there is no spending cap, you must add your own mechanisms to stop runaway activity.

Add
```
limits.cpu_ms
```
to Workers. Measure the p99 CPU time in production and set the limit slightly above it. Raising the limit too high allows an infinite loop to become billable
Put rate limiting in front of public APIs, authentication, and write endpoints. Without rate limiting, all high-volume bot traffic becomes billable
For repositories that have a zone, use WAF rate-limiting rules. For repositories without a zone, use a Workers Rate Limiting binding
Make Queue consumers, Durable Object alarms, and retry processing idempotent. Do not allow them to re-enqueue themselves
Set attempt limits for re-enqueueing and retries
Configure budget alerts on the account. Use them to detect unexpected spending quickly, not to stop it automatically

Reducing writes and operations

Writes and list operations can cost one to three orders of magnitude more than reads.

Batch KV writes and D1 and Durable Objects row writes
Do not write a value if it has not changed
Do not call KV
```
list()
```
on every request. Design the system to retrieve values directly by key
Put Durable Objects to sleep using WebSocket Hibernation and alarms. While awake, the full 128 MB allocation is billed even if it is not being used
Do not keep Durable Objects awake with
```
setTimeout
```
or outbound connections
Do not use R2 Infrequent Access for small files that are written and read frequently. Its per-operation cost is higher than Standard

Filtering logs and traces

Logs and traces are both billed based on volume.

Do not continuously store logs for every request in Cloudflare. Sample only the required volume with
```
head_sampling_rate
```
If logs are only being sent externally, use
```
persist: false
```

Estimation and production verification

Follow measure-dont-guess.

Before finalizing the design, multiply the expected traffic by the number of Worker invocations, rows, operations, and log events per visit to estimate the monthly cost
After deployment, review production usage through the dashboard's Billable Usage view or the GraphQL Analytics API. If actual usage differs from the estimate, revisit the design

cloudflare-caution

NPX Install

Tags

SKILL.md Content (Chinese)

cloudflare-caution

Why this skill is needed and the desired outcome

Unit prices and how billing works

Materializing reusable results

Safeguards against runaway execution

Reducing writes and operations

Filtering logs and traces

Estimation and production verification