Cloudflare Zombie API Endpoints: A Practical Cleanup Plan

By Greg Nowak. Last updated 17 July 2026.

Cloudflare can now identify saved API endpoints that have received no traffic for 32 days. That is useful, but the cf-risk-zombie label is a prompt to investigate—not permission to delete a route.

A quiet endpoint might be obsolete. It might also support a monthly process, a seasonal service, a partner integration or an emergency workflow that nobody has exercised recently. The real job is to establish ownership, gather evidence and retire the route without surprising customers or delivery teams.

What the zombie label actually tells you

Cloudflare applies the label to saved endpoints after 32 days without traffic and reevaluates endpoints daily. It does not confirm that the origin route has been removed, that no client still expects it or that the endpoint is absent from deployed code.

Deleting an endpoint from Endpoint Management does not delete the application route. It removes the endpoint from Cloudflare's managed inventory and permanently removes its historical metrics. If the route remains live at the origin, it can still be reached unless another control catches it.

Signal	Question to answer	Safe next action
`cf-risk-zombie`	Is the route genuinely unused or merely quiet?	Check logs, owner, release history and client commitments.
Discovered but unmanaged	Why is live traffic reaching an undocumented route?	Save the endpoint, normalize its path and assign an owner.
In OpenAPI but absent from traffic	Is the specification ahead of production or out of date?	Test the deployed route and reconcile the specification.
Approved for retirement	What will happen if an old client calls it?	Deploy the retirement control, monitor and then remove it.
Unknown endpoint traffic	Should unidentified routes be logged or blocked?	Use a scoped fallthrough rule after validating the inventory.

A decision matrix for moving from a Cloudflare signal to an accountable cleanup decision.

Build an inventory you can defend

Use three views together: observed traffic, Endpoint Management and the OpenAPI specification. None is authoritative on its own.

API Discovery groups similar paths and hostnames, helping teams turn requests such as /customers/123 and /customers/456 into one logical endpoint. Discovery is an Enterprise feature and derives its results from traffic using machine-learning and session-identifier methods. A route missing from Discovery therefore needs investigation, not an automatic “dead” verdict. Cloudflare also warns that unsaved discovery results can disappear.

Endpoint Management is available on all plans and accepts endpoints from Discovery, schema uploads or manual entry. Use variables consistently—for example, /api/users/{var1} or {hostVar1}.example.com—so one logical route does not become dozens of misleading records.

Assign every questionable endpoint a service owner and a business owner. The service owner verifies code and infrastructure; the business owner confirms whether a customer, supplier or internal process still depends on it. For agency-managed systems, include the client-side owner rather than assuming the agency can authorize retirement.

Use a change-controlled retirement workflow

Record the evidence. Add request counts, relevant log windows, schema status, known consumers and the Cloudflare label to a cleanup ticket. Do this before deleting the managed endpoint because its historical metrics cannot be restored.
Search beyond Cloudflare. Check origin logs, gateway logs, repositories, integration documentation, scheduled jobs and support records. Pay particular attention to low-frequency machine-to-machine calls.
Classify the route. Mark it as active, legacy but required, scheduled for deprecation or safe to remove. “Unknown” is a valid temporary state, but it needs an owner and review date.
Plan client behaviour. Decide whether callers should receive a deprecation response, a replacement route, an explicit error or a temporary redirect. Authentication and authorization must remain enforced throughout the transition.
Deploy and observe. Remove or disable the origin route through the normal release process, then monitor Cloudflare and origin events for unexpected callers.
Clean the inventory last. Delete the Endpoint Management entry only after the application change is verified and the evidence has been retained elsewhere.

Turn the inventory into enforcement

Schema validation protects only operations added to Endpoint Management. Dashboard schema uploads can add endpoints automatically. When schemas are uploaded through the API or Terraform, Cloudflare says the endpoints must be parsed and added separately. Missing that step creates a dangerous gap between “schema uploaded” and “route protected.”

Cloudflare currently accepts OpenAPI 3.0 schemas, including 3.0 patch versions, but not OpenAPI 3.1. Validate the file before rollout and confirm that its host, method and path tuples match production.

Where your plan permits it, begin with schema violations logged and review real traffic before blocking. Cloudflare's current plan table is important here: Free, Pro and Business plans expose a Block-only rule action, while Enterprise plans can use Log or Block. On a block-only plan, test the schema carefully in a non-production environment or narrowly scope the first deployment.

Once the managed inventory is trustworthy, consider a fallthrough rule for requests that match no saved endpoint. Cloudflare exposes cf.api_gateway.fallthrough_detected for custom logic. Scope the rule to API hostnames or root paths so an API control does not accidentally catch ordinary website traffic.

Use scanning as a separate assurance step

Cloudflare's Vulnerability Scanner remains an open-beta, API-driven feature for Enterprise API Shield customers. Its current BOLA workflow needs an OpenAPI schema, a target environment and two credential sets: an owner and an attacker who should not access the owner's resources.

That can reveal authorization problems, but it is not a substitute for endpoint cleanup. Scans send real requests, so use controlled accounts, agree the target and timing, and make result review part of the release or security backlog.

Make zombie review routine

A one-off sweep will decay. Review new discoveries and risk labels on a regular schedule, keep OpenAPI changes tied to releases, and require an owner and retirement date for every legacy exception. The useful outcome is not an empty dashboard; it is an inventory that engineering, operations and the business can trust.

If your Cloudflare inventory has become a mixture of forgotten routes, incomplete schemas and uncertain ownership, Greg can help turn it into a controlled cleanup plan without treating live integrations as collateral damage.