I've been evaluating Helicone for a week now, implementing it on a staging environment for a mid-sized internal tool that uses OpenAI's API. The integration was straightforward, but I'm encountering a critical issue: the Helicone dashboard shows zero requests across all time periods, while our application is fully functional and processing calls without error.
According to our logs, the requests are being routed through the Helicone proxy URL, and we are receiving valid responses. The API keys and proxy setup follow the documentation. This isn't a mere UI glitch; it undermines the core value proposition of monitoring and cost analysis. Without accurate request tracking, the service is unusable for its intended purpose of TCO oversight and vendor management.
I need to understand the root cause. Has anyone experienced this with a successful backend integration? My immediate concerns are data privacy—where is our request metadata going if not to the dashboard—and the reliability of the SLA. Before I proceed to a production contract, I must have confidence in the observability layer.
Current setup is the standard Node.js client, with the Helicone endpoint and headers applied. No custom routing.
Trust but verify — especially the fine print.
Yeah that's really strange if the proxy is working and you're getting responses. I'm new to Helicone too but I had something similar once. For me, it was an issue with the header being stripped somewhere in our middleware before the request actually hit their endpoint. Maybe double-check the headers are present in the final outbound call?
Also, the data privacy point is a good one. If it's not showing in the dashboard, where *is* it going? Did you check if the requests are maybe logged under a different project or API key in your Helicone account? I've accidentally used the wrong key before.
Curious, are you using any custom rate limiting or a firewall that could be blocking the analytics pingback?
Headers being stripped is a classic culprit, but let's not overlook the simpler explanation that the analytics payload itself is being blocked. I've seen teams deploy this behind a WAF with outbound rules that silently drop requests to unrecognized third-party domains, or use a proxy that filters non-standard POST bodies.
Checking for a different project is good advice, but the more likely scenario is that the telemetry endpoint - which is separate from the proxy gateway - is failing. Helicone's dashboard is just a frontend to that aggregated data. If the handshake for the request metadata fails, your app keeps working but the observability layer starves.
It's another case of adding complexity that doesn't fail gracefully. You now have two critical paths: the API call and its shadow. When the shadow fails, you're left with a functional system and a broken dashboard, which is arguably worse than no dashboard at all because it creates a false sense of no data.
monoliths are not evil
You're spot on about the telemetry endpoint. It's a separate call that can fail silently. I'd add that network timeouts on that analytics ping are super common, especially if your proxy is under heavy load. The request gets through, but the metadata gets dropped.
I've also seen teams using Helicone's cloud proxy while their egress firewall blocks the exact subdomain used for logging. Makes the dashboard a ghost town. Maybe OP can check their proxy logs for any 4xx/5xx on the non-OpenAI paths?
That "false sense of no data" is the real killer. You think you have zero cost, but the bills are still running. 😬
Happy customers, happy life.