We can plug in a call ID and find all the logs for that call in order. We can see every request going to the transcriber, the LLM, and the speech model, and every result.
Tejas SiripurapuHead of Core Engineering, VapiIf a customer reports that something strange happened during a call, Vapi’s support team starts with its ID. A five-minute call can produce tens of thousands, or even hundreds of thousands, of log events. Entering the ID in Axiom narrows that volume to the ordered history of one conversation. The team can see what each model received, what it returned, and where the call began to diverge from the expected path.
A voice agent should respond within roughly 250 to 500 milliseconds. In that window, audio must be transcribed, an LLM must produce a response, and a speech model must begin turning it back into sound. Even the smallest delay at any step can jeopardize that response time.
Who they are
Vapi gives developers the building blocks for voice agents that people can speak with over the phone or on the web. Customers can choose the transcriber, language model, and speech model that fit their product rather than accepting one fixed stack.
You can think of a voice agent like a Lego build. You have three blocks: a transcriber, an LLM, and a speech model. You stack them up.
Tejas SiripurapuHead of Core Engineering, VapiThat choice is central to Vapi’s product, and part of what makes its infrastructure demanding. Every combination creates another real-time path to understand. Traditional streaming systems can hide some delay with a buffer. Conversation cannot. The evidence has to be detailed enough to identify what happened at a particular moment in a particular call.
Vapi now handles more than three million calls a day. At that rate, the platform is running at roughly one billion calls a year. Tejas says the old infrastructure heuristic of designing for ten times current scale no longer feels sufficient for a fast-growing AI company. Tenfold growth can arrive sooner than the planning cycle expects.
Logging was the missing layer
Tejas joined Vapi around December 2024 as a backend engineer. He soon stepped into a wider infrastructure gap that covered scaling, fallbacks, failovers, resilience, and observability.
Vapi had an all-in-one observability platform, but its breadth made it difficult to know which signals mattered and where the application needed richer instrumentation. The pricing also became harder to reconcile with Vapi’s growth. Calls run on ephemeral workers that spin up and down, so infrastructure grows with call volume. Host-oriented pricing made that growth harder to predict.
The team self-managed Prometheus, Thanos, and Grafana for metrics, with Jaeger for traces. That worked. Logging at Vapi’s volume proved harder to operate on its own.
We went the self-managed route, which worked for metrics and traces. But logging is a special beast.
Tejas SiripurapuHead of Core Engineering, VapiVapi needed one dependable place for its application and system logs. It needed to send a large volume, keep it long enough to investigate, and query across it without turning observability into another infrastructure team to build and staff.
Why Axiom fit the way Vapi scales
Vapi began using Axiom as that centralized logging destination. Tejas points to three reasons it stayed: the cost of retaining a large volume of data, the ability to query across it, and the support Vapi receives as its needs change.
The biggest reason it’s hard to leave Axiom is the ability to ingest large amounts of data, keep it there for a long time, and query across large datasets.
Tejas SiripurapuHead of Core Engineering, VapiThe economics matter because Vapi’s infrastructure expands with the calls it handles. More customers create more call traffic. More traffic requires more clusters, hosts, and services. Each of those produces more logs.
Enterprise growth makes the curve steeper. Vapi began selling more deliberately to enterprises in mid-2025. A successful deployment can spread from one part of a company to many, bringing a step change in call volume rather than a gradual rise.
Vapi’s data layout is changing with that scale. Its original production and staging datasets grew broad, spanning many services. Vapi and Axiom are now working together to improve query efficiency with smaller, service-scoped datasets. For Tejas, that direct partnership is part of the reason Axiom has lasted through each new stage of growth.
Life with Axiom
Axiom gives Vapi a shared production history for three kinds of investigation: agents can explore unfamiliar problems, support and engineers can reconstruct individual calls, and different teams can work from the same evidence as the company grows.
Known questions for humans, ambiguous questions for agents
Tejas draws a useful line between two investigation modes.
For a familiar issue, the human often knows the query to run. Axiom monitors watch log thresholds and page Vapi’s on-call engineer roughly once a week. The engineer can open the monitor’s query, inspect the events that caused it to fire, and summarize matching logs by count. The resulting graph shows when the problem began and when the count returned to zero.
Unfamiliar issues begin differently. Tejas estimates that roughly six out of ten debugging investigations have no runbook. The investigator may not yet know which service, code path, or event matters.
Vapi gives agents access to the codebase and to Axiom through MCP. An agent can trace an observed issue to the code that emits a relevant log, inspect the surrounding events, and follow evidence across services. A skill gives it an investigation method and a reporting format. The engineer gives it the problem, then reviews and challenges what comes back.
There’s a part of my ego that wants to say I drive the agent all the time. But the truth is, you give it a description of the problem, let it run, and review its findings at the end.
Tejas SiripurapuHead of Core Engineering, VapiVapi first explored that pattern with a background agent available through Slack. Axiom was one of the first tools connected to it, which meant anyone in the workspace could ask the agent to investigate an incident against Vapi’s logs. Vapi has since connected Axiom to a hosted background agent so people can ask questions about those logs from Slack.
The agent does not replace the engineer’s understanding of the system. It assembles context and investigates several directions before the engineer applies judgment. Known questions remain fast human workflows. Ambiguous questions get an agent’s breadth and patience.
One place for the call, not one tool for everything
Axiom is not Vapi’s only observability product. Another platform handles metrics, traces, and some infrastructure logs. The division is deliberate: Axiom holds much of the application and business-logic data that explains what happened inside a call. For that workload, Tejas says Axiom makes it affordable to ingest and retain large volumes of logs, then query the full history to reconstruct a call. Other providers Vapi considered either charged substantially more to meet that need or could not meet it.
The data comes from several parts of the stack. Application, service, and Kubernetes logs flow into production and staging datasets. Cloudflare Logpush supplies access data for the API and dashboard. An AWS integration brings in CloudWatch logs. Together, they give Vapi a shared view across Cloudflare, AWS, Kubernetes, and the application.
System-level telemetry can show that latency changed or a database is under pressure. Axiom answers a different question: What did every component do during this customer’s conversation?
That is why the call ID has become such a practical unit of investigation. Customer support uses it regularly to reconstruct individual calls. Engineers use the same data when the question reaches deeper into the platform.
The call is still the unit of truth
Vapi’s use of Axiom has grown with the platform. Roughly 75% of its engineering, product, and design group uses Axiom to debug, and customer support uses it regularly. Each group starts from a different question, but works from the same production history.
At three million calls a day, the surrounding infrastructure is always changing. The investigation can still begin with one identifier from one customer. Support can reconstruct the call directly. An on-call engineer can connect it to a known error pattern. An agent can inspect the code and logs when the path is unclear.
The value becomes clearest when Tejas imagines that shared history disappearing.
If Axiom wasn’t here on Monday, we’d lose engineering time, productivity, and money. Our customers would feel it too.
Tejas SiripurapuHead of Core Engineering, VapiTejas’s advice to another infrastructure hire is to prepare for growth in both platform traffic and the number of teams that need to understand it. More traffic creates more events to investigate; a larger organization brings engineers, support, and other teams with different questions. Keeping the logs together gives those teams a common starting point. Agents help people find and make sense of the evidence they need.