Workflow guide · Cloudflare + Datadog
Cloudflare to Datadog: workflow automation guide
A practical guide to connecting Cloudflare and Datadog around combining edge and application signals for incident response, including workflow design, implementation, controls, measurement, and the UbiGrowth path for extending the automation into a broader operating workflow.
Introduction
What connecting Cloudflare and Datadog actually means.
Cloudflare sees traffic before your application does: which requests were blocked, which were cached, where they came from, and how long the edge took. Datadog sees what happened after. During an incident, the difference between those two views is often the whole answer — is the origin slow, or is the edge shedding load?
This workflow forwards the edge signals that matter into Datadog so a single request path can be reasoned about end to end, and so a rule change at the edge is visible on the same timeline as the application metrics it affects.
This is most valuable to teams whose incidents currently begin with an argument about whether the problem is the edge or the origin. If traffic is modest and lightly cached, the same effort is better spent on application instrumentation first.
- Source system
- Cloudflare
- Destination system
- Datadog
- Direction
- One-way, event driven
- Product path
- The UbiVibe platform
The problem
Remove the handoff, not the accountability.
Teams often keep Cloudflare and Datadog in separate operating loops, which creates duplicate entry, stale records, and unclear ownership.
Edge logs are the highest-volume data source most teams have. A modest site produces far more request logs than application logs, and forwarding them without sampling turns an observability improvement into a budget problem within a billing cycle.
The other issue is semantic. An edge request and an application request are not one-to-one — cached responses never reach the origin, and blocked requests never become application events at all. Correlating the two requires a shared request identifier, not an assumption that the counts should match.
A useful integration should move a defined business object or event between systems with an explicit owner, exception path, and measurable outcome.
The goal is not to automate every possible action. Start with the smallest repeatable workflow that removes a real handoff or reporting delay.
You're likely here because
- You cannot tell whether an outage is edge-side or origin-side.
- A WAF rule change breaks legitimate traffic and nobody correlates it.
- Cache hit ratio is discussed but never charted next to origin load.
- Bot and attack traffic is invisible in application dashboards.
Architecture
How the Cloudflare to Datadog workflow executes.
Every stage is separable, which is what makes the workflow debuggable: the connection, the triggering event, the context assembled around it, the interpretation of what should happen, the write into Datadog, and the validation that proves it landed.
Step 01
Authorize the Cloudflare connection
The Cloudflare connection is authorized for the specific zones in scope with permission to read analytics and configure log delivery, and the Datadog connection receives the forwarded stream. Zone-level scoping keeps a shared account from leaking unrelated properties into your telemetry.
Step 02
Detect the triggering event in Cloudflare
Logs are pushed from the edge on a defined schedule, along with firewall events, and analytics metrics such as cache hit ratio, edge response time, and status code distribution. Sampling is set at the source for high-volume request logs.
Step 03
Assemble tenant-scoped context
Correlation depends on a shared request identifier propagated from the edge into the application, so an edge log line and an application trace refer to the same request rather than merely the same second. Zone, service, and environment tags align edge data with the existing tag taxonomy.
Step 04
Interpret the outcome with ARIA
ARIA can summarize an edge anomaly against application state: a spike in blocked requests alongside a drop in origin traffic reads differently from a spike in origin errors with flat edge volume, and stating that distinction early is the most valuable thing an incident summary can do.
Step 05
Execute the write in Datadog
Edge metrics, firewall events, and sampled logs land in Datadog, with configuration changes such as WAF rule or cache setting updates annotated onto the timeline so a self-inflicted incident is identifiable in seconds.
Step 06
Validate, provenance, and measure
The workflow checks that log delivery is actually running, because push-based delivery can stall quietly, and it tracks the ratio of edge to origin requests as a health signal in its own right.
Data flow
What actually moves, and what stays where it is.
Most integration disappointment comes from an unstated assumption about which system owns what. This is the concrete mapping for Cloudflare to Datadog, including the things that deliberately do not move.
Workflow blueprint
A five-stage operating path.
01
Define the triggering event in Cloudflare.
02
Normalize the record or context that needs to move into Datadog.
03
Apply validation, permissions, and any required human approval before a consequential action runs.
04
Write the approved result into Datadog and preserve enough context to audit what happened.
05
Measure completion, exceptions, cycle time, and downstream business impact before expanding scope.
Implementation path
Build for reliable operations, not demo-day automation.
- 01
Confirm which system owns each field and which system remains the source of truth.
- 02
Map identities, required fields, permissions, and duplicate-handling rules before enabling writes.
- 03
Run a bounded pilot with real records and explicit rollback or retry behavior.
- 04
Add alerts for failed, stale, or ambiguous handoffs rather than silently skipping them.
- 05
Expand only after the workflow is completing reliably and the receiving team is using the result.
Controls
Controls that matter.
Control 01
Use least-privilege access and keep tenant or workspace boundaries explicit.
Control 02
Require human review for legal, clinical, financial, employment, safety, or other consequential decisions.
Control 03
Preserve provenance so operators can see which source record caused an action.
Control 04
Define retry, escalation, and idempotency behavior before increasing automation volume.
Measurement
Prove the workflow is better.
Instrument these before expanding scope. A workflow that completes reliably but never changes the downstream number is automation for its own sake, and the only way to know the difference is to measure both.
Examples
What this looks like in practice.
Six concrete paths through the workflow, including the cases where the correct behavior is to stop and ask rather than write into Datadog.
Origin slow or edge shedding load
Origin response time rises while edge volume stays flat. The two series on one dashboard answer immediately whether the problem is upstream, which is usually the first ten minutes of an incident call.
A WAF rule that blocks real users
A new rule deploys and blocked requests jump for a specific path. The annotated configuration change sits directly under the spike, turning a lengthy investigation into a rollback decision.
A cache configuration change
Cache hit ratio drops and origin load rises in step. Charted together, the cause is obvious; charted separately in two products, it becomes a capacity discussion that never mentions the cache.
Stalled log delivery
Log push fails after a credential rotation. The delivery check reports it, rather than the team assuming a suspiciously quiet traffic chart means a quiet night.
A bot surge that never reaches the origin
Automated traffic is absorbed at the edge. Application metrics stay flat while edge volume spikes, and seeing both on one chart prevents a capacity investigation that was never needed.
An issue affecting one region
Errors concentrate in a single geography. Edge data carries the location dimension application telemetry usually lacks, which turns "some users report problems" into a specific, actionable fact.
Limitations and considerations
What this workflow does not do.
- Edge log volume is the dominant cost driver. Sample aggressively for routine traffic and keep full fidelity for errors and security events rather than paying for both.
- Edge and application request counts will never reconcile exactly, because cached and blocked requests never reach the origin. Treat that gap as information, not as a data quality bug.
- Correlation requires propagating a request identifier through the stack. Without it, you have two adjacent datasets rather than one connected view.
- Request logs can contain personal data in URLs, headers, and query strings. Redaction rules belong at the source, before forwarding.
- This gives visibility, not protection. Deciding which traffic to block remains a security policy decision made in Cloudflare.
- Some Cloudflare analytics are available only at certain plan levels, so the achievable granularity depends on your subscription.
FAQ
Questions teams ask before building this.
Should every edge request log be forwarded?
No. Sample routine successful traffic and keep full fidelity for errors, blocked requests, and security events. Unsampled forwarding is the single most common way this integration becomes indefensible on cost.
How do edge logs correlate with application traces?
Through a request identifier propagated from the edge into application headers. Without a shared identifier you can only correlate by timestamp, which fails precisely when volume is high.
Why do edge and origin request counts differ?
Because cached responses and blocked requests never reach the origin. The ratio between them is a useful health signal, and expecting them to match will send you chasing a discrepancy that is working as designed.
What is the highest-value thing to chart first?
Configuration change annotations against edge and origin metrics. A large share of edge incidents are caused by a rule or cache change, and making that visible turns long investigations into quick rollbacks.
How do you connect Cloudflare to Datadog?
Start by defining the business event in Cloudflare, the record or action required in Datadog, the authoritative fields, and the exception path. Then test the smallest bounded workflow with real records before expanding.
What should remain the source of truth?
Choose ownership field by field. Avoid bidirectional writes unless both systems have explicit conflict and deduplication rules.
Can this workflow run without human review?
Routine low-risk handoffs can be automated once reliability is proven. Consequential legal, clinical, financial, employment, safety, or other high-impact decisions should retain explicit human control.
How should failures be handled?
Failures should be visible, retryable, and attributable to the source event. Silent drops create misleading downstream data and should be treated as an operational defect.
What metrics matter most?
Track completion rate, cycle time, exception rate, duplicate rate, human interventions, and the downstream business outcome the workflow is intended to improve.
Do I need to replace either system?
No. The operating pattern is to preserve useful systems of record and connect them through governed workflows rather than forcing a stack replacement.
Where does ARIA fit?
ARIA can help interpret the requested outcome, identify the systems involved, and route the work into Launch, Grow, or the broader UbiVibe operating layer.
Where should I start?
Choose one repetitive handoff with clear ownership and measurable value. Prove it end to end, then expand the workflow only after the first path is reliable.
Where teams use this pattern
Start with ARIA
Ask ARIA to run this workflow.
Describe the outcome and ARIA defines the steps, connects the systems that matter, and runs the work — recording what it did and pausing for approval where you require it.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Turn this workflow into an operating system.
Start with ARIA to define the outcome, connect the systems that matter, and route the work into the right product without rebuilding your stack from scratch.