How to debug a production error with Claude Code (2026)

To debug a production error with Claude Code, give it what your repository cannot show: the error, its stack trace, and the logs and trace of one failing request. Paste them in, or connect your monitoring tool's MCP server. Then have Claude reproduce the error in a failing test, fix the cause, and check production after the deploy.

This guide is the workflow, step by step, with the prompts to use at each one. We checked every Claude Code command and behaviour below against Anthropic's docs on October 28, 2026, and cite them inline. Fixter is our product; it comes up once, in the section on giving Claude production context, next to the other ways to do it.

What Claude Code can see in production, and what it cannot

On your machine, Claude Code has your code, your tests and your terminal. That is enough for an error you can trigger yourself: it runs the command, reads the stack trace and fixes it. A production error is different. It happened on a server Claude has never seen, for a user whose data it does not have, maybe hours ago. Anthropic's own advice for Claude Code starts here: tell Claude what it cannot see, and connect the tools that hold it.¹

So step one of every production debug is the same: get the evidence into the session. There are four ways, and they differ in how much Claude can find on its own.

Commands from the Claude Code and Kubernetes docs, checked October 28, 2026.¹,²,³,⁵

How to debug a production error with Claude Code, in five steps

The steps are the ones you would follow by hand. What changes is that Claude does the reading and the typing, and you check its reasoning at each step.

1. Get the error and its context into Claude Code

A message like "checkout is broken" gives Claude nothing to work with. What it needs, in order of value: the full stack trace (not just the error message), the logs of one failing request, when it started, which version was deployed, and who it affects. Anthropic's docs make the same point for any bug: tell Claude how to reproduce it, and whether it is intermittent or consistent.²

If you paste, paste all of it in one message and say what you do not know.

> Checkout is failing in production since this morning. Here is the
  stack trace, one log line from a failing request, and what I know.

  TypeError: Cannot read properties of null (reading 'currency')
      at priceCart (src/cart/price.ts:41)
      at POST /api/checkout (src/routes/checkout.ts:88)

  log    14:12:03 error checkout failed cart=c_8812 user=u_301 region=CH
  when   first seen 09:40 UTC, after the 2.18.0 deploy at 09:31
  who    only some users; I can't reproduce it on my machine

  Find the cause. Don't change anything yet.

If it is in a file or a command, pipe it. Claude Code reads standard input like any Unix tool, and the Claude Code docs show exactly this pattern.¹ kubectl logs takes --since for a time window and --previous for the container that crashed before the current one.⁵

# in a terminal: the last hour of logs from one pod, into Claude
kubectl logs checkout-7d9f --since=1h | claude -p "what is failing here, and since when?"

# or a log file you downloaded
cat error.log | claude -p "group these errors and show the first one"

If your monitoring tool has an MCP server, connect it once and let Claude ask the questions. This is where the work gets faster, because Claude can follow up on its own: open the stack trace, pull the logs of the failing request, then the trace. With OpenTelemetry, every span in a request carries the same trace ID, so the logs and spans of one failing request can be pulled together.⁶ Connecting a server is one claude mcp add line in a terminal and /mcp inside Claude Code to sign in.³ We compare the servers in 10 monitoring MCP servers for Claude Code, and walk through the connection in how to connect Claude Code to your logs.

> What is the newest error in checkout-service? Show the stack
  trace and the logs and trace of one failing request.

> When did it start, and how many users has it hit since then?

> Compare a failing request with a passing one on the same route.
  What is different about the input?

2. Reproduce it in a failing test

Before any fix, get the error to happen outside production. Anthropic's own example prompt for a bug asks Claude to write a failing test that reproduces it, then fix it.¹ The failing request from step 1 gives you the inputs: the route, the payload shape, the user's region or plan, the data that was missing.

> Write a failing test that reproduces this with the inputs from the
  failing request: a cart in region CH whose price has no currency.
  Run it and show me it fails for the same reason.

If it will not reproduce, that is information. The difference between your laptop and production is usually where the cause is: an environment variable, real data that is messier than your fixtures, or load. We cover those gaps in why your app works locally but breaks in production. Ask Claude to compare a failing request with a passing one on the same route; the difference in input is often the answer.

3. Find the cause, not the symptom

The tempting fix for Cannot read properties of null is a null check. Sometimes that is right. Often the real question is why the value is null in production and not locally, and a null check just moves the failure somewhere quieter. Ask Claude to explain the mechanism and point at the evidence before it edits anything.

Plan mode helps here: Claude reads files and proposes a plan, but makes no edits until you approve. Press Shift+Tab until the status bar shows plan mode, or start with claude --permission-mode plan.² Two questions narrow most production errors quickly: what changed at the time it started (a deploy, a config change, a dependency), and what the failing requests have in common. Claude can answer the first from git log and the second from the logs.

Some tools now do this first round for you and hand Claude a finished analysis with cause, evidence and who is affected. How that works, and how far to trust it, is in AI root cause analysis for production errors.

4. Fix it, and make Claude show the proof

With a failing test in place, the fix has a clear finish line: the test goes green and nothing else breaks. Anthropic recommends giving Claude a check that comes back pass or fail, and asking for evidence (the command it ran and its output), because "all tests pass" on its own tells you little.¹ Two built-in commands help: /verify has Claude build and run the app and look at the result, and /code-review reviews the diff in a fresh subagent that never saw your conversation.¹

Check whether the fix needs a data change as well. If old records are missing a field, guarding the code stops the error but leaves the bad data in place. Fix both, or write down why not.

5. Verify in production after the deploy

This is the step most people skip, and the only one that tells you the fix worked. The test proves the case you reproduced. Production tells you whether it was the case your users hit. After the deploy, ask Claude whether the error has happened since, and compare the error rate on the route before and after.

> 2.18.1 went out at 15:05. Has the TypeError in priceCart happened
  since then? Show the error rate on POST /api/checkout before and after.

Without a monitoring tool you would watch the logs for a while and hope. With one, the error either stops or it does not, and a good tool tells you if it comes back later. If you do not have that yet, set up error monitoring with Claude Code before the next one.

How to keep Claude Code read only in production

Give Claude Code read access to your telemetry and nothing more. Debugging needs the evidence, not the power to change production, and four habits keep it that way.

• Read telemetry, do not touch production. Debugging needs logs and traces, not write access to your servers or database. Use a read-only role or token where your tool has one. If Claude does need the database, see how to keep Claude Code read-only on your production database.
• Logs are untrusted text. They contain whatever your users typed. Anthropic's security guidance is to avoid piping untrusted content straight into Claude and to review commands before you approve them.⁴ Read what Claude proposes after it reads logs.
• Connect only servers you trust. The Claude Code docs say to verify you trust each MCP server before connecting it.³ Use the vendor's official server.
• Mind what you paste. Stack traces and logs can carry tokens, emails and customer data. See how to redact sensitive data in Claude Code.

Giving Claude Code production context with Fixter

Fixter is ours, so weigh this section with that in mind. Fixter finds and fixes the issues in your app in production, from your coding agent: errors, failing infrastructure, slow requests and downtime. It finds the root cause and fixes it: in your agent over MCP, or as a pull request ready for your review. Nothing to learn, built for small teams.

For this workflow, it covers steps 1 and 5 when you have no monitoring yet. Your app sends logs, traces and metrics over standard OpenTelemetry, and you set it up by pasting one line into Claude Code.

# paste this into Claude Code in your project: it does the whole setup
Read fixter.dev/llms.txt and set up Fixter.

# or connect the MCP server alone, in a terminal
claude mcp add fixter --transport http https://mcp.fixter.dev
# then run /mcp inside Claude Code to sign in

Once it is connected, Claude can search logs, open a whole trace, pull a trace's spans and logs together in one call, list the issues Fixter has found, read one issue with its occurrences and affected routes, and mark it resolved after the fix.⁷,⁸ Fixter groups the same error into one issue, tells you by email when a new one appears (Slack too, once you route it there), and reopens a resolved issue if the error comes back, so step 5 does not depend on you remembering to check.⁹ Each issue also has a Copy fix prompt button: a ready claude "..." command with the stack frames, evidence and trace and log ids, to paste into your terminal in the repository.⁹

MCP access is on every plan, including Free with 10 GB a month. Paid from €20 a month.¹⁰ If your errors already live in Sentry or Datadog, use their MCP server instead; we compare the two in Datadog MCP vs Sentry MCP.

Frequently asked questions

How do I debug a production issue with Claude Code?

Give Claude what your repository cannot show it: the full stack trace, the logs and trace of one failing request, when it started and which version was running. Paste them in or let Claude query them over your monitoring tool's MCP server. Then ask it to reproduce the error in a failing test, explain the cause, fix it, and check production after the deploy.

Can Claude Code read my production logs?

Not on its own. Locally it sees your code and whatever you paste or pipe in. To let it read production, connect the MCP server of the tool that holds your logs with claude mcp add, then sign in with /mcp inside Claude Code. Sentry, Datadog, Better Stack, Grafana, Fixter and others have one. If your platform has a log command, such as kubectl logs, Claude can also run that.

How do you fix production issues?

In order: find out exactly what fails and for whom, reproduce it outside production, find the cause rather than the symptom, fix it with a test that proves it, deploy, and confirm the error stops in production. Skipping the last step is the common mistake: a fix that passes locally can still miss the production case.

What if I cannot reproduce the error locally?

Then the difference between your laptop and production is the clue. Compare configuration, data and load, and have Claude read the trace of a failing request to see the exact inputs and the step that failed. Write the test from those inputs. Most errors that only happen in production come down to config, real data or scale.

Is it safe to give Claude Code access to production?

Give it read access to telemetry, not write access to production systems. Use a read-only role or token where the tool offers one, keep database credentials out of the session, and connect only MCP servers you trust. Logs contain text your users typed, so treat what Claude reads from them as data, not instructions.

Do I need a monitoring tool to debug with Claude Code?

Not for one error you can copy from a terminal. You need one when the error happened hours ago, on a server you cannot see, or to users who never told you. Without stored logs and traces there is nothing for Claude to read, so the first production error you cannot explain is usually the moment to set one up.