My LLM API Calls Were Failing Silently. Here's the Logging Setup I Wish I Had Earlier

The first few LLM API bugs I hit in production were easy to notice. The request failed. The user saw...

venerdì 26 giugno 2026 New tab

1,974 words~9 min read

The first few LLM API bugs I hit in production were easy to notice.

The request failed. The user saw an error. I opened the logs, found the stack trace, fixed the obvious thing, and moved on.

The harder bugs were quieter.

The API still returned a response, but it was slower than usual. A fallback model kicked in without anyone noticing. Token usage crept up over a few days. A retry made the request succeed, but doubled the latency. Streaming worked most of the time, except when it didn't.

Nothing looked "down." The app just started feeling worse.

My LLM API Calls Were Failing Silently. Here's the Logging Setup I Wish I Had Earlier

My LLM API Calls Were Failing Silently. Here's the Logging Setup I Wish I Had Earlier

Related reading

5 Mistakes Every Developer Makes When Using LLM APIs for the First Time

Structured Outputs: How We Stopped Parsing LLM Responses by Hand

Catch LLM Schema Drift Before It Breaks Production

How I Cut My LLM API Costs by 70% Without Touching My Code

Making LLM Calls Reliable: Retry, Semaphore, Cache, and Batch

Making LLM outputs auditable: the provider abstraction pattern

Related reading

5 Mistakes Every Developer Makes When Using LLM APIs for the First Time

Structured Outputs: How We Stopped Parsing LLM Responses by Hand

Catch LLM Schema Drift Before It Breaks Production

How I Cut My LLM API Costs by 70% Without Touching My Code

Making LLM Calls Reliable: Retry, Semaphore, Cache, and Batch

Making LLM outputs auditable: the provider abstraction pattern