By Greg Nowak. Updated 26 August 2026.
Cloudflare Workers often enter a business through a perfectly reasonable side door. A developer validates a webhook, fixes campaign redirects, proxies an awkward API, or cleans up form data before it reaches the CRM. The code is small, deployment is quick, and nobody needs to provision another server.
Six months later, that small Worker may sit between the website and a revenue-critical system. It has routes, credentials, environment-specific configuration and failure modes—but no clear owner. That is when useful integration glue starts becoming shadow IT.
The answer is not a heavyweight governance programme. It is a short integration register that connects each Worker to the business process it supports. The register should let a competent person understand what runs, why it matters, where it is configured and how to recover it.
When is a Worker more than “just a script”?
Treat a Worker as a production application component when it accepts external events, changes customer-facing behaviour, calls another system, reads credentials or affects business records. A Worker that validates a partner webhook and forwards a lead is business logic, even if its source file is only a few dozen lines long.
Name the workflow before cataloguing the technology. “Website lead intake” tells an operations lead far more than form-proxy-prod. It also makes the consequences of failure visible: lost enquiries, delayed orders, incorrect attribution or a customer journey that behaves differently from the documented website.
Cloudflare now distinguishes three HTTP entry points. Custom Domains are intended for Workers acting as the origin; Routes place a Worker in front of an existing origin; and workers.dev is positioned for personal or non-business-critical use. Record which model each production Worker uses, along with Cron Triggers, queues and other event sources.
What belongs in a Cloudflare Workers integration register?
| Register field | What to record | Review trigger |
|---|---|---|
| Purpose | Business process, users affected and criticality | Process or supplier changes |
| Entry points | Routes, Custom Domains, schedules, queues and event sources | DNS, traffic or schedule changes |
| Dependencies | APIs, service bindings, KV, D1, R2, queues and upstream origins | A binding or API changes |
| Credentials | Secret names, purpose, owning system and rotation owner—never values | Rotation or access changes |
| Delivery | Repository, Wrangler configuration, environments and approval path | Every production release |
| Operations | Logs, alerts, safe identifiers and expected failure behaviour | An incident or traffic increase |
| Recovery | Known-good deployment, rollback steps and data limitations | Binding or schema changes |
Separate the business owner from the technical maintainer. The owner decides whether the workflow is still required and how much interruption is acceptable. The maintainer knows how to test, deploy and diagnose it. In a small organisation one person may fill both roles, but the responsibilities should still be explicit.
How to audit the Workers already in your account
Begin with the Cloudflare account and the repositories your team believes are authoritative. Do not assume they match. Dashboard edits, abandoned experiments and Workers deployed from a former supplier’s machine are precisely what the exercise is meant to uncover.
For a repository-backed Worker, these Wrangler commands provide a useful starting point:
npx wrangler deployments list --jsonnpx wrangler deployments status --jsonnpx wrangler secret list
The secret command lists names rather than values, which is exactly what an inventory needs. Cloudflare advises storing sensitive values as secrets rather than plaintext variables. Wrangler configuration can also declare names under secrets.required; deployments then fail when a required secret is missing. Use that technical safeguard alongside the register’s ownership and rotation information.
Next, trace every entry point to its destination. For each route, domain or trigger, identify what calls the Worker, what the Worker calls, how requests are authenticated and what happens when a dependency times out. Test the unhappy path as deliberately as the successful one. A webhook that silently returns success after a failed CRM write is operationally more dangerous than one that fails visibly.
Then compare the deployed configuration with version control. Routes, bindings, compatibility settings, observability configuration and environment differences should be reproducible. Cloudflare recommends treating Wrangler configuration as the source of truth rather than relying on dashboard changes.
Logging should answer business questions
Production logs should make a failed workflow explainable without recording complete payloads or credentials. For an integration Worker, useful fields might include an external event ID, event type, validation outcome, downstream service, response status and elapsed time. Avoid passwords, tokens, form contents and unnecessary personal data.
Cloudflare Workers Logs supports structured JSON, which makes individual fields searchable and filterable. Head-based sampling can control volume, but sampling needs to fit the workflow. A low-volume payment or lead event may justify complete logging; a high-volume redirect Worker may not. Record the decision so an incident responder knows whether a missing event means “not received” or merely “not sampled”.
Application logs and Cloudflare Audit Logs solve different problems. Application logs explain what the Worker did with a request. Account Audit Logs show who or what changed Cloudflare resources through the dashboard or API. Both help during an incident, but neither explains the business purpose as clearly as the register.
A rollback button is not a recovery plan
Cloudflare can roll a Worker back to a previous deployed version with Wrangler or the dashboard. However, connected resources are not rolled back with the code. A previous version may also be unusable if a bound KV namespace, R2 bucket or queue has been removed, or if data structures have changed.
Your recovery note should therefore name a known-good deployment and state what must remain compatible. For important Workers, rehearse the procedure after meaningful binding or schema changes. “Use rollback” is not enough when the older code expects resources that no longer exist.
Keep the register alive without creating bureaucracy
Store the register somewhere the delivery and operations teams already work. Make updating it part of adding a route, binding, credential, trigger or production dependency. Review critical entries after incidents and when a staff member or agency leaves. A small accurate register is better than an elaborate inventory nobody trusts.
If your Workers estate has grown through years of quick fixes, Greg can help map the routes, dependencies, owners and recovery gaps, then turn the result into a maintenance plan your team can actually use.
Related on GrN.dk
- Cloudflare Turnstile on lead forms: the widget is the easy part
- ChatGPT apps need a permissions map before they touch company data
Related on GrN.dk
- Form Spam Is a Lead-Quality Problem: How to Harden Your Intake Flow
- Agentic AI: What It Is, How It Works, and When to Use It
- Cloudflare Page Rules Debt: How Quiet Configuration Drift Breaks Business Websites
Need help with this kind of work?
Ask Greg about a Cloudflare Workers review Get in touch with Greg.
