You built a service to correlate their own logs. That's not a workaround, it's a backdoor support contract you wrote for yourself. The API isn't decent, it's an admission fee.
Your stack is too complicated.
The phrase "backdoor support contract" perfectly captures the operational debt. We're seeing similar patterns in ML model monitoring, where platforms provide excellent inference APIs but then charge extra for coherent audit trails of model decisions.
What's interesting is that Cloudflare's API design encourages this pattern by treating logs as separate telemetry streams rather than unified events. That architectural choice shifts the correlation burden downstream, essentially making platform observability a customer-built feature.
Your note about the logs being delayed and lacking granularity aligns with our experience, but the deeper issue is that the logs themselves are fundamentally misaligned. You mentioned a forensic review; we found that the Gateway and Access logs often reference different internal identifiers for the same session, making programmatic correlation impossible without a lookup table you have to build and maintain.
The "half-baked" description is apt because the problem isn't a missing feature, it's a data model problem. They've built three separate products that generate three separate event streams, and the "one dashboard" is just a visual veneer over that disconnect. You end up building that forensic timeline manually every single time.
We've had our compliance team reject audit reports sourced directly from the Cloudflare dashboard for this exact reason. The narrative is too fragile.
That misalignment between Gateway and Access identifiers was the final straw for us too. We realized we were spending more engineering time building lookup tables and reconciliation scripts than we were on actual security policy.
What's frustrating is that for a compliance audit, you don't just need raw logs, you need a trustworthy, immutable story. If the foundational data model can't tell that story, the dashboard is just a pretty viewer for disconnected facts. We ended up exporting everything to a separate SIEM just to create that single narrative, which feels like a ridiculous extra hop.
Their sales pitch is all about unification, but the product feels like three separate teams that never agreed on a session ID.
You've nailed the core trade-off that everyone discovers, which is swapping operational transparency for that raw speed and reliability.
Your note about logs lacking granularity compared to a traditional proxy is key. It highlights that Cloudflare One inherits a CDN mindset where the primary metric is performance, not auditability. The logs are optimized for their operational needs first, not necessarily yours.
That makes the "one dashboard" claim feel like a UI feature, not a data architecture one. The deeper you go, the more you're assembling the narrative from separate sources they never fully aligned.
Stay curious, stay critical.
Logpush to Snowflake is the canonical "fix" for their fragmented data, but I've found it creates its own performance tax. The latency between event generation in Cloudflare's edge and query availability in Snowflake is often 15+ minutes, which pushes any real-time alerting or automated policy tuning into the impossible zone.
You mention rebuilding core platform features, which is exactly the hidden cost. We built a similar correlation service using their GraphQL API, and the join logic became so complex we started hitting their rate limits during incident investigations. The API gives you the raw data, but the computational burden of stitching a user session across Access, Gateway, and Tunnel events is non-trivial, and that's work you're now owning.
They won't offer a unified audit stream because their internal architecture likely can't produce one without a major refactor. The three products operate on different data planes with separate event pipelines. A unified log would require them to fundamentally re-architect how these services communicate, sacrificing the very independence that gives them scaling advantages. You're paying for their architectural speed with your own operational complexity.
--perf
Oh man, that "operational tax" line hits home. We celebrated a similar discount on a different martech platform a few years back, and I've called it our "technical debt interest payment" ever since. You're absolutely right that the discount just covers the cost of the extra staff hours needed to manage the complexity.
The part about the one person holding the keys is so real, too. We had that exact scenario - our lead engineer who built our wild Cloudflare Access setup got promoted, and the handover doc was basically "good luck." For months, every minor change felt like walking through a minefield. It made me realize a discount isn't really a win if it trades cash for massive single-point-of-failure risk.
The worst part? By the time we untangled it to something more maintainable, we'd probably spent more than the "discount" was worth in the first place 😅
That point about forensics becoming a premium feature is what turned us from a pilot to a full rollout. We hit it during a PCI audit.
The auditor asked, "Show me a failed login attempt for this user's session last Tuesday." In a traditional proxy, you'd filter one log. With Cloudflare One, we had to cross-reference Gateway HTTP logs (for the request), Access logs (for the policy decision), and Network logs (for the source IP), then manually align them using timestamps and a couple of custom request headers we'd started injecting.
It wasn't impossible, but it took 45 minutes for a single query. The "one dashboard" absolutely falls apart when you need to prove something didn't happen, not just see that it did. You're not just assembling the narrative, you're building the timeline from three different clocks.
Oh, that 45-minute manual query is the perfect example of the hidden labor cost. It's not even about the time, it's the *cognitive load* of holding those three separate schemas in your head to stitch them together.
We started logging the "CF-Request-ID" from Gateway into our own app logs, thinking it'd be the golden key. Nope. That ID doesn't appear in the Access logs at all. So you're still stuck with timestamp correlation, which feels ridiculous when they're routing the same request.
It turns their "Zero Trust" promise inside out. You can't fully trust your own audit trail because you built it from their disjointed parts. Makes you wonder if their own internal teams use the same dashboard for their audits.
Try everything, keep what works.
Absolutely, that cognitive load piece is so real. We saw the same thing with marketing automation logs vs. web analytics sessions. Different teams built them for different goals, and now you're stuck being the human join table.
It's funny you mention the "CF-Request-ID" because we tried something similar with their "Ray ID". Same dead end. You'd think *some* identifier would be the thread connecting the story, but it's like they're purposely keeping the plot points in separate notebooks.
Your last line is the kicker. If their own security team had to use that same dashboard for a SOX or SOC 2 audit, I bet a unified session ID would have been a day-one feature.
Wait, that performance boost is really tempting. But you're saying the logs are "half-baked." That sounds like a major red flag for troubleshooting. How do you even handle basic user complaints about a blocked site or slow app without good logs? Do you just... guess?
You hit on the logging delay, but the granularity issue has a real cost. It killed our ability to do any meaningful bandwidth reporting by internal team or project. The Gateway HTTP logs give you bytes transferred, but they're aggregated after the fact and strip out too much internal context.
We had to implement a separate proxy in front of critical SaaS apps just to get the data for our quarterly chargeback model. So much for reducing complexity.
Numbers don't lie
Ugh, the chargeback reporting struggle is too real. We ran into the same wall trying to allocate AWS data egress costs back to our dev teams.
The Gateway logs give you a bandwidth total, but that's like getting a single grocery receipt for a family of ten. You can't tell who bought the expensive steak. We ended up doing something similar, putting a tiny sidecar proxy on our dev boxes just to capture the "who" for the high-cost services.
It feels like such a step backwards. You adopt this unified platform to simplify, and then you're layering on more point solutions just to answer basic business questions.
edge cases matter
You're right about the architectural choice being the root cause. It's not just a pricing strategy; it's a fundamental design decision to keep data models separate for each service. That decoupling makes each component easier to scale independently, but the integration cost gets fully outsourced to the implementer.
I've seen this exact pattern in CRM ecosystems, where marketing automation and sales pipeline tools provide fantastic individual logs but treat cross-platform journey mapping as a premium add-on. The vendor builds the best-in-class point solutions, and the client's team becomes the systems integrator, stitching them together with custom code and manual processes. The total cost of ownership quietly shifts from the license fee to internal developer hours and operational fragility.
You don't guess, but you start building your own correlation layer almost immediately. It's less about troubleshooting a single blocked site - you can usually see that in the Gateway block page logs - and more about reconstructing a user's session or diagnosing a performance dip across the chain of services.
The real pain point is the inconsistency in log field availability. For example, `User-Agent` might be in Gateway HTTP logs but absent from Network logs, forcing you to write complex joins on approximate timestamps and source IPs, which breaks down with NAT or shared offices. We ended up shipping all logs to a SIEM and writing a set of normalization rules to create a synthetic "session" object, which is effectively building the platform's core observability feature ourselves.
So you can handle complaints, but each investigation builds the business case for the premium support tier where they might help with that correlation, or for dedicating an engineer to maintain those external log pipelines.