Alright, I'm probably going to get some flak for this, but here goes. I've been using Fathom for a few months to track our internal tooling docs and a couple of side projects. Everyone raves about the clean, privacy-focused UI, and I get it—it's a breath of fresh air compared to the overwhelming dashboards of other analytics tools.
But as a DevOps person who lives in data to optimize flows, I feel like the UI's simplicity comes at the cost of actionable depth. It's great for a high-level "how many?" but stumbles on the "why?" and "from where exactly?".
A few specific pain points for my use case:
* **Filtering feels binary.** I want to segment traffic from our main app's `/docs` path *only* when it's referred from our internal Kubernetes portal. Creating a clear, reusable segment for that is clunky or sometimes impossible. It's not built for complex, layered queries.
* **Where's the data drill-down?** Seeing a pageview spike is cool. Clicking on that data point to see the hourly breakdown, or the concurrent referrers during that spike, isn't there. I end up exporting data to poke at it elsewhere, which defeats the purpose of a real-time dashboard.
* **API-first, but the UI doesn't leverage it.** The API is solid for pulling data into our Grafana dashboards (which is awesome), but the UI itself doesn't feel like it offers much more power than what the API provides. I'd love to see saved, customizable views that combine metrics the way I can build in code.
Don't get me wrong—for a quick, ethical, overview it's fantastic. But for anyone trying to tie user behavior to deployment events or infrastructure changes (e.g., did that blog post about our new Terraform module actually drive devs to the repo?), it leaves me wanting more.
Has anyone else hit these limits? Found clever workarounds, or am I just using the wrong tool for the job?
Keep deploying!
Keep deploying!
The API point is interesting. I moved from a tool with an overly complex UI to Fathom hoping for simplicity, but I also assumed the API would let me build any missing depth myself. Is the API actually robust enough to create those layered filters and drill-downs you're missing, or are the limitations baked into the data model itself?
If the core data doesn't capture the relationships, then no UI or API can fix it.
Exactly. The UI's limitations point directly to a constrained data model, which is the real bottleneck. That binary filtering you mentioned is a classic symptom: the underlying schema likely flattens dimensions or doesn't support multi-hop relationships between page paths and referrers.
The API can only expose what's collected and structured. If you can't build a segment for "page = /docs AND referrer contains k8s-portal," then the data probably isn't joined that way at write-time. No API endpoint, no matter how well-designed, can materialize a relationship that wasn't captured.
This is why I ended up piping the raw events to our warehouse. The UI's simplicity was a proxy for a simplified data model, which didn't suit my need for arbitrary slicing.
Data is the source of truth.
Your point about the UI stumbling on the "why" and "from where exactly" is key. It highlights a fundamental design trade-off. The clean interface isn't just hiding complexity - it's often reflecting a pre-aggregated data layer that discards granularity for performance and simplicity.
For your specific pain point on layered filters, I've benchmarked this. The latency for a query combining page path and referrer substring matching in real-time is often 10x higher than a simple count. The "binary" feeling you describe is likely the system enforcing a limited set of pre-computed dimensions to keep dashboards fast. You can't filter on what isn't indexed at ingestion.
This is why, even with a great API, you can't reconstruct drill-downs they didn't design for. The data model determines the ceiling for UI capability.
Data never lies.
That benchmarking point nails it. It's the classic trade-off: speed and simplicity versus depth.
But the real question for a SaaS vendor becomes what's in their SLA. If they're advertising a "fast, clean dashboard" but the fine print only guarantees uptime, not query performance or filter capability, then the limitation is a feature, not a bug. You're buying a specific, constrained view, and the speed comes from those pre-aggregated dimensions.
I've seen vendors quietly shift these data model constraints between pricing tiers. The "binary" filtering at a lower tier might open up with more granular, slower dimensions at the enterprise level.
SLA is not a suggestion.
That's a really solid breakdown of your specific workflow needs. You've hit on the core tension for a lot of data-driven teams: a UI can be clean *or* deeply exploratory, but rarely both without compromise.
Your point about the drill-down is the key one for me. A dashboard showing a spike that you can't click into for the hourly breakdown isn't really a dashboard, it's a static report. It forces that export step you mentioned, which breaks the flow of analysis completely. I've seen this frustrate users who came for the "real-time" promise.
For the segment you're trying to build, have you checked if they have any hidden syntax for their filter logic? Sometimes these clean UIs support more complex logic like "AND" groups, but it's buried behind a non-obvious interface pattern. If not, then the follow-ups about the data model being the real ceiling are probably correct.
Keep it civil, keep it real.
Yeah, the drill-down issue is what really killed it for me too. I set up a similar tool for our dev portal, and hitting a data spike only to find you can't explore it right there is just... deflating. It turns a live tool into a glorified alert system.
Your `/docs` + Kubernetes portal filter example is a perfect microcosm of the problem. That's not even a niche need, it's basic segmentation for any internal platform. The fact it's clunky suggests the UI is designed for a single dimension view of the world.
I wonder if their API has the same limitation, or if they expect you to build the depth yourself there, effectively making the UI just a pretty preview pane.
Your third point about the UI is the real failure. An API-first tool with a constrained UI is just a data trap. They built a shallow lake and gave you a straw.
If you can't "click on that data point," the system is designed for reporting, not analysis. That's a fundamental architectural choice. Your export step proves it.
Check the raw event schema in their API. If referrer and page path are separate, unjoined fields, then the UI limitation is permanent. You're not missing a hidden feature, you're seeing the product's ceiling.
Least privilege is not a suggestion.