Hot take: Cloudflare One is a VPN killer, but a logging headache.

You're right about the speed and experience, it's definitely a step up from most VPNs. The logging part is a common pain point though, especially when you need to correlate a specific request back to a user for an audit.

We ended up piping everything to our SIEM early on. Cloudflare's own dashboards are fine for quick looks, but for compliance, having all the logs in one place with our other security events was necessary. It simplified the "jumping between places" problem you mentioned.

Have you looked at setting up Logpush for Gateway yet? It gets you a more consolidated stream, but you'll still need to map those logs to your internal user directory for full attribution.

Yeah, that dashboard log fragmentation is a classic gotcha. You can't just pull a user report and see their DNS, HTTP, and network flows side-by-side in one table, which is exactly what an auditor wants.

We ended up writing a Lambda that stitches together the different Logpush streams (Gateway DNS, HTTP, and Network) into a single "user session" view before sending it to our SIEM. The real headache was mapping Cloudflare's device IDs back to our Okta directory - their Zero Trust logs don't natively include the user's email on every row. Had to join it with the Access audit logs.

If you don't have a SIEM yet, even dumping the raw Logpush JSON to an S3 bucket and querying with Athena is better than clicking around the admin panel. Retention's cheap that way too.

That's a solid workaround for the log correlation problem. We used a similar approach with Splunk, but found the delay between the different Logpush streams could sometimes create gaps when stitching sessions together. Had to add a timestamp buffer in the parsing logic.

Your point about joining with Access audit logs is crucial. It's easy to miss that the user identity often only appears there, not in the raw network logs. Did you run into any issues with the API rate limits when querying for those joins at scale?

> feels like a VPN killer

Spoken like someone who's never had to reconstruct an incident from fragmented logs during an audit. The speed is nice until you need to prove who did what.

It's a common issue because it's by design. They sell you on "no network, no problem" but gloss over the fact you now rely entirely on their opaque logging pipeline for visibility. You think you're jumping between places now? Wait until you need logs from six months ago.

Yes, you need a SIEM. Immediately. Logpush to S3/Athenia is the bare minimum. And good luck mapping those device IDs back to actual humans without building a whole join pipeline. Another "simple" cloud tool that just moves the complexity somewhere else.

You're right about the user experience, it's a big improvement. The logging and correlation piece is definitely a common hurdle.

For a small dev team, you might not need a full SIEM rollout on day one, but you should start planning for it if compliance is a driver. The "jumping between places" feeling in the dashboard doesn't scale well for audits. Setting up Logpush to a cheap storage bucket is a good first step to centralize the raw data, even if you're just querying it manually for now. That gives you the retention and a single source of truth while you figure out the user-mapping piece others have mentioned.

It's less about needing a SIEM "immediately" and more about acknowledging that the native dashboard isn't built for forensic review. Getting the logs out early saves a scramble later.

Your point about centralizing the data early is the correct foundational step. I'd add a specific caveat: while setting up Logpush to S3 for retention is straightforward, the schema evolution for those logs can break your downstream parsing if you're not careful.

Cloudflare has introduced new fields and changed JSON structure in minor updates without always flagging it as a breaking change. If you start querying manually with Athena today, and then six months from now need to run a historical query, your SQL might fail because a field like `DeviceID` was renamed to `EndpointDeviceID`. Building a simple ingestion layer that normalizes the schema version, even if it's just a glue job that runs weekly, prevents that forensic scramble later. You're not just saving logs, you're preserving your ability to read them.

> the user experience is amazing

Yeah, that's the hook. The logging is the catch.

It's absolutely a common issue. The dashboard is built for ops, not forensics. You're going to need those logs centralized somewhere you can query them properly, because piecing together user activity from the admin panels isn't sustainable.

For a small team, you don't need a full SIEM day one, but you need to start. Set up Logpush to a cheap bucket now. Get the raw data flowing to one place. The compliance ask means you'll need to map requests to users, and that's a join problem between Gateway logs and Access logs. Doing that manually will waste your time.

If you wait, you'll have a data gap when the next audit hits. Start simple: S3 + Athena queries. That'll at least give you a single source to search.

You hit on a key distinction I see a lot. The admin dashboard is great for an ops engineer checking a current issue, but it's not built for the kind of historical analysis an auditor needs.

> mapping those logs to your internal user directory

This is the silent project multiplier. We've found the joins aren't real-time, so depending on your SIEM, the user attribution in your alerting can lag by a few minutes. That can be a problem for automated response playbooks.