Cloudflare Zombie API Endpoints: How to Retire Them Safely

By Greg Nowak. Reviewed 28 August 2026.

Cloudflare’s cf-risk-zombie label is useful precisely because it starts a conversation. It is not a delete button.

Cloudflare applies the label when a saved API endpoint has received no traffic for 32 days. Risk scans run every 24 hours. That makes the label a good cleanup signal, but a poor retirement decision on its own. A quiet endpoint may serve a month-end job, seasonal campaign, partner integration, disaster-recovery process or client nobody remembered to ask.

The safe response is to connect technical evidence with business ownership. For agencies, that also means distinguishing changes the agency can implement from retirements the client must authorize.

What Cloudflare has—and has not—proved

The label tells you that Cloudflare has not observed traffic to a saved endpoint during its 32-day window. It does not prove that the origin handler has gone, that deployed software no longer references it or that an external consumer has stopped expecting it.

There is another important distinction: deleting an operation from Cloudflare’s Web Assets inventory is not the same as removing the application route. Deletion stops Cloudflare tracking that operation, and its previous historical metrics cannot be restored. If the handler remains deployed, callers may still reach it unless another security control blocks them.

Build an inventory that the business can trust

Use at least three views: Cloudflare’s Web Assets inventory, traffic evidence and the current OpenAPI specification. None should be treated as the sole source of truth.

Cloudflare API Discovery normalizes similar URLs into logical operations and can add candidates to the inventory. However, Discovery has meaningful thresholds: requests must return a 2xx response, and an endpoint needs at least 500 requests within a continuous 10-day period to appear. Worker-originated requests are also excluded from its thresholds. Absence from Discovery therefore says little about low-volume, failing or test-harness traffic.

Normalize operations consistently by HTTP method, hostname and path. For example, record /api/users/{var1} rather than allowing each customer ID to appear as a separate route. Otherwise, the inventory exaggerates the number of endpoints and hides ownership problems inside noisy data.

Give every questionable operation two named owners:

• A service owner who can inspect code, infrastructure, logs and releases.
• A business owner who can confirm customer, supplier and internal-process dependencies.

For an agency-run platform, the client-side business owner should approve retirement. The agency can gather evidence and execute the release, but should not silently accept commercial risk on the client’s behalf.

Use a change-controlled retirement workflow

1. Preserve the evidence first. Record request history, labels, schema status, known consumers and relevant log windows in a ticket. Do this before deleting the operation because Cloudflare’s historical metrics cannot be recovered.
2. Search outside Cloudflare. Check origin and gateway logs, repositories, scheduled jobs, integration documentation, support records and recent releases. Extend the review window to cover monthly, quarterly and seasonal processes.
3. Classify the route. Use a small set of outcomes: active, legacy but required, deprecation planned, approved for removal or ownership unknown. “Unknown” is acceptable temporarily, provided it has an owner and review date.
4. Plan caller behaviour. Decide whether old clients need a replacement route, deprecation response or explicit error. Keep authentication and authorization controls in place throughout the transition.
5. Retire through the application release process. Disable or remove the origin handler, update the specification and monitor Cloudflare, origin and support events for unexpected callers.
6. Clean Cloudflare last. Remove the managed operation only after the application change is verified and the audit trail is stored elsewhere.

Move from inventory to enforcement carefully

Once the inventory is credible, it can support stronger controls. Cloudflare’s current Schema Validation 2.0 compares traffic with an uploaded OpenAPI schema and exposes violations through cf.schema_validation.uploaded.violated. The detection does not block requests by itself; mitigation is configured separately with WAF custom rules.

Dashboard uploads can add schema operations automatically. API or Terraform workflows require the operations to be added to Web Assets separately. Missing that step leaves a gap between “schema uploaded” and “operation evaluated.” Cloudflare currently supports OpenAPI 3.0 patch versions, not OpenAPI 3.1, and recommends validating the document before upload.

A fallthrough rule can then match requests that do not correspond to known operations. Cloudflare provides the field cf.api_gateway.fallthrough_detected for custom logic. Scope it narrowly to the intended API hostnames or root paths, inspect representative traffic and account for emergency or infrequent routes before enforcing a block.

Make zombie review part of operations

A one-off cleanup starts decaying as soon as the next deployment lands. Review new operations and risk labels regularly, connect OpenAPI changes to releases, and give every legacy exception an owner and review date.

The goal is not an empty Cloudflare dashboard. It is a smaller, explainable API surface that engineering, operations and the business agree is real.

If your inventory combines forgotten routes, incomplete schemas and unclear client ownership, Greg can help structure the evidence, decisions and rollout so cleanup does not become an avoidable outage.

Related on GrN.dk

• How to Bulk Delete Cloudflare DNS Records Safely—Without Browser Console JavaScript
• Cloudflare Page Rules Debt: How Quiet Configuration Drift Breaks Business Websites
• Cloudflare’s Enforce DNS-Only Switch: Test Your Origin Before an Incident

Need help with this kind of work?

Plan a safe API cleanup with Greg Get in touch with Greg.

Sources

• Endpoint labeling service
• Endpoint Management
• API Discovery
• Schema validation