Investigate an error users report

Give Claude Code the symptom and where users see it; it traces the code path, read-only, and explains the likely cause with evidence and a proposed fix.

Task: Investigate an error users report · Other tasks

Fill in the details

What users are seeing (required)

Where they see it (required)

Details from the reports

Optional. When it started, who is affected, and the steps that trigger it.

Stack trace or logs

Optional. Remove secrets, tokens and customer data first.

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

Your prompt (you can edit it)

Users are seeing [fill in: What users are seeing] on [fill in: Where they see it]. Investigate and tell me what is going on.

Start from the code that handles [fill in: Where they see it] and follow the request path: handlers, services, database queries and calls to other systems. Check recent commits on that path.

Rules:
- Investigate only. Do not edit code, change config, restart anything or write to any data store. If a fix is clear, describe it and wait for me.
- Read-only commands, and running existing tests locally, are fine.
- Keep what you confirmed separate from what you suspect. If the evidence is not enough, say what is missing instead of guessing.

Report:
1. What is going on, in two or three sentences.
2. The cause, or the most likely causes, each with evidence: file and line, commit, or log line.
3. Who is affected and under which conditions, as far as you can tell.
4. A proposed fix, and a test that would reproduce the problem before the fix.
5. What you could not check, and what information would settle it.

2 required fields are empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

Users report a specific problem at a specific place, such as an endpoint or a page, and you want an explanation before anyone changes code.
You know where the problem shows up but not where it starts. Claude can follow the code path from that point and check recent commits along it.
You have a stack trace or log lines from the reports and want them matched to the code that produced them.

When not to use it

The whole service is down or degrading and you need to correlate logs, deploys and config changes. Use the production incident template, which is built around that timeline.
You already know the cause and only need the fix. Ask for the fix directly, with a test that reproduces the bug first.
The logs contain customer data you may not share with an AI tool. Redact them first, or describe the error in the details field instead.

Why this structure

The symptom and the location are two required fields, because together they tell Claude what to look for and where to start. That gives the investigation a narrow starting point instead of the whole codebase.
Starting from the code that handles the location and following the request path gives the search a direction: from where users see the problem toward where it begins.
The investigate-only rule asks Claude to diagnose, propose a fix and wait, so you read the explanation before anything in code or data is changed.
Pasted logs go first inside <logs> tags, and the rules say to treat them as data. Log lines from a user-facing feature often include user input.
The report separates confirmed causes from suspected ones and asks for evidence with each, so you can check the reasoning instead of trusting a confident story.
Point 4 asks for a test that reproduces the problem, which gives the later fix a check it can be measured against.

Example input (fictional)

What users are seeing

500 errors

Where they see it

/api/settings

Details from the reports

Since yesterday afternoon. Only older accounts seem affected. It happens when saving notification settings.

Stack trace or logs

2026-10-06 15:42:10 ERROR settings.update: TypeError: Cannot read properties of null (reading 'channels')
    at mergeNotificationPrefs (src/settings/prefs.ts:37:22)
    at updateSettings (src/settings/handler.ts:81:15)

Follow-ups to send Claude

Write the failing test from point 4 and run it to show that it reproduces the problem. Do not fix anything yet.
Use subagents to check whether other endpoints call the same function with data that could be missing in the same way.
Draft a short status update for support: what users see, who is affected, and that a fix is in progress. No technical detail.

Common mistakes

Describing the symptom without a location, such as "settings are broken". Give the endpoint, page or action so Claude starts on the right code path.
Letting Claude fix the problem during the investigation. Keep the investigate-only rule, read the cause, then ask for the fix with a test.
Pasting only the error message without the stack trace. The trace usually points to the exact function, which shortens the search.

Investigate a production incident: Give Claude Code the symptom and when it started; it checks logs, recent deploys and config changes, then names the most likely cause with evidence.
Debug an error: Turn an error message and the code around it into a ranked list of likely causes, a check for each, and a fix you can try.
Find and fix a failing test: Name the failing test; Claude Code runs it, traces the failure into the source, explains the cause, fixes it and shows the passing test output.

See all templates

Sources

Claude Code docs: Prompt library (Anthropic documentation)
Claude Code best practices: Provide specific context in your prompts (Anthropic documentation)
Claude Code best practices: Avoid common failure patterns (Anthropic documentation)
Claude Code best practices: Use subagents for investigation (Anthropic documentation)