By Greg Nowak. Updated 28 September 2026.
Cloudflare’s cf-risk-zombie label is a useful prompt for investigation. It is not evidence that an API endpoint is safe to delete.
Cloudflare applies the label when a saved endpoint has received no traffic for 32 days, with risk scans running every 24 hours. That window can expose forgotten API surface, but it can also catch legitimate month-end processes, seasonal services, disaster-recovery tooling and low-volume partner integrations.
The practical response is to connect Cloudflare’s signal with application evidence and an accountable business decision. For an agency-managed platform, that usually means the agency investigates and implements the change while the client approves the retirement risk.
What the zombie label actually proves
The label proves that Cloudflare recorded no traffic for the saved operation during its 32-day window. It does not prove that the route has been removed from the application, that deployed clients no longer reference it or that an external partner has agreed to stop using it.
Deleting an operation from Cloudflare’s Web Assets inventory is also different from removing the underlying application route. Inventory deletion stops Cloudflare tracking the operation, and its previous historical metrics cannot be restored. If the handler still exists at the origin, callers may continue reaching it unless the application, gateway or another security control rejects them.
| Evidence | Likely interpretation | Next decision |
|---|---|---|
cf-risk-zombie only |
The saved operation has been quiet for 32 days. | Investigate; do not retire it yet. |
| Quiet in Cloudflare and origin logs | The route may be obsolete or rarely used. | Check scheduled jobs, contracts, code and owners. |
| Present in OpenAPI but receiving no traffic | The specification may be ahead of production or out of date. | Test the deployment and reconcile the specification. |
| Traffic reaches an unknown operation | A live route is missing from the managed inventory. | Identify and classify it before enabling fallthrough blocking. |
| Removal approved by both owners | The evidence and business impact have been reviewed. | Remove at the origin, monitor and then clean the inventory. |
Build an inventory you can make decisions from
Compare three views: Cloudflare’s Web Assets inventory, traffic at the gateway and origin, and the current OpenAPI specification. None is a complete source of truth by itself.
Cloudflare API Discovery has important thresholds. To appear in Discovery, an endpoint must receive at least 500 qualifying requests during a continuous 10-day period, and those requests must return a 2xx response from the Cloudflare edge. Requests originating directly from a Cloudflare Worker—including Worker-based test harnesses—do not count toward those thresholds. Absence from Discovery therefore does not establish that a low-volume, failing or test-only route is unused.
Record each operation consistently by HTTP method, hostname and normalized path. Treat GET api.example.com/users/{userId} as a distinct operation from the corresponding DELETE request, but do not create a separate inventory entry for every user ID. Also record the environment, API version, authentication expectations, data sensitivity and known consumers.
Assign two named owners:
- Service owner: responsible for code, infrastructure, logs, releases and technical rollback.
- Business owner: responsible for confirming customer, supplier, contractual and internal-process dependencies.
If either owner is unknown, that is a finding—not permission to delete. OWASP treats incomplete API inventories and missing retirement strategies as a security risk because deprecated versions can remain exposed with weaker controls.
Use a change-controlled retirement workflow
- Preserve the evidence. Before changing Cloudflare, capture the operation identity, labels, traffic history, schema status, known consumers and review period in a ticket. Inventory metrics cannot be recovered after the full operation is deleted.
- Search beyond the dashboard. Review gateway and origin logs, repositories, mobile and desktop clients, scheduled jobs, integration documentation, support records and recent releases. Choose a review window long enough to cover monthly, quarterly and seasonal activity.
- Classify the route. Use clear states such as active, legacy but required, deprecation planned, approved for removal or owner unknown. Every temporary exception should have an owner and another review date.
- Plan for old callers. Decide whether they need a replacement endpoint, a communicated deadline or an explicit error. Keep authentication, authorization and rate controls in place while the route is deprecated.
- Remove the capability at its source. Disable or remove the origin handler through the normal application release process. Update tests, documentation and the OpenAPI document in the same change where practical.
- Observe before final cleanup. Monitor Cloudflare events, origin logs, failed requests and support channels. Keep a tested rollback path for integrations that were missed.
- Clean Cloudflare last. Delete the managed operation only after the application change is verified and the audit evidence is stored elsewhere.
Move from visibility to enforcement carefully
Once the inventory is trustworthy, it can support stronger controls. Cloudflare Schema Validation 2.0 compares requests with an uploaded OpenAPI schema and exposes violations through cf.schema_validation.uploaded.violated. Detection is always on once the uploaded profile is available, but it does not mitigate traffic by itself; blocking or other action is configured separately with WAF custom rules.
Dashboard uploads can add schema operations to Web Assets automatically. With API or Terraform workflows, those operations must be added separately. Cloudflare currently relies on OpenAPI 3.0, including its patch versions, and does not support OpenAPI 3.1 for Schema Validation. Validate the document before uploading it and send representative traffic before enforcing violations.
A fallthrough rule can identify requests that do not match known operations using cf.api_gateway.fallthrough_detected. Scope it to the intended API hostnames or root paths, review representative matches and account for emergency and infrequent routes before choosing a blocking action. Otherwise, a cleanup project can turn an incomplete inventory into an outage.
Make retirement a routine operational decision
API inventories start drifting again with the next release. Review newly discovered operations and risk labels regularly, connect schema changes to deployment work, and require an owner and expiry date for every legacy exception.
The objective is not an empty Cloudflare dashboard. It is an API surface that engineering, operations and the business can explain—and retire without surprises.
If your inventory contains forgotten routes, incomplete schemas or unclear client ownership, Greg can help turn the evidence into a safe cleanup and rollout plan.
Related on GrN.dk
- Cloudflare AI Gateway: Put LLM Budgets in the Request Path
- Cloudflare Service Keys Stop in September: Find Every Caller
- How to Bulk Delete Cloudflare DNS Records Safely—Without Browser Console JavaScript
Need help with this kind of work?
Plan a safe API cleanup with Greg Get in touch with Greg.
