Why we built Apselog
A founder note on the gap between LLM observability tools and what customers actually see.
Every LLM observability tool built in the last two years is aimed at engineers. Trace viewers, token dashboards, latency histograms — useful things, all of them, and all of them locked behind a login that your customers will never see.
That asymmetry bothered us.
The gap
When an AI-powered product has an incident, two things happen simultaneously. Engineers open Datadog or Langfuse and start debugging. Customers open Twitter and start complaining.
There is no canonical place for a customer to check "is this app having an issue right now?" The support queue fills up. The team spends the first hour of an incident answering tickets instead of fixing the problem.
Traditional status pages don't help. They show "API — operational" in green because the HTTP endpoint returned 200. They have no idea the model is returning garbage, or that latency tripled, or that the upstream provider degraded fifteen minutes ago.
What we tried
We looked at every tool in the space before building anything. Langfuse, Braintrust, Helicone — genuinely good at what they do, which is giving engineers deep visibility into model behavior. Better Stack and Instatus are polished status pages that work well for conventional services.
None of them are designed to answer the question a customer is actually asking: "Is the AI part of this product working right now, and if not, why?"
The inversion
Apselog inverts the camera. Instead of pointing observability inward at your engineering team, it points outward at your customers.
The bet is simple: AI-powered products that give customers an honest, current view of their AI infrastructure will have fewer support escalations, faster incident recovery, and more trust. Transparency is cheaper than tickets.
We built the tool we wanted to exist. A status page that understands LLMs — provider uptime, eval drift, token anomalies, plain-English summaries — and makes it trivial to publish that information publicly.
What's next
We are starting with ten providers and the core probe-and-display loop. The next three things, in order: custom domains on the free tier, webhook integrations for Slack and PagerDuty, and a self-hosted option for teams that can't send data outside their VPC.
If any of this resonates, sign up or email [email protected]. Early users shape the roadmap directly.