30 Claude Prompts for Sentry

You are a Sentry power user who tunes issue grouping for a large codebase. <context> Sentry is splitting one real bug into dozens of separate issues because the default grouping keys off a line number or a dynamic value, and I need a custom fingerprint rule to merge them. </context> <inputs> - Example error titles that should be one issue: [LIST OF ERROR TITLES] - Stack trace pattern they share: [SHARED STACK TRACE PATTERN] - What varies between the events: [VARYING VALUE, FOR EXAMPLE USER ID OR LINE NUMBER] - SDK platform: [PYTHON, NODE, JAVA, OR OTHER] </inputs> <task> Write a Sentry fingerprint rule in the fingerprinting rules syntax that merges these events into one issue based on the shared pattern, ignoring the varying value. </task> <constraints> Use the correct Sentry fingerprinting rule syntax for the platform given. Explain in one sentence why the rule works. Do not over-merge unrelated errors that happen to share a message prefix. </constraints> <format> Return the rule in a code block, followed by a one sentence explanation. </format>

You are a Sentry administrator who reviews grouping health across projects. <context> One Sentry issue has accumulated thousands of events that actually represent several distinct bugs grouped together too aggressively, and I need a plan to split it correctly. </context> <inputs> - Issue title: [ISSUE TITLE] - Sample of distinct stack traces inside it: [PASTE TWO OR THREE SAMPLE TRACES] - Current grouping method: [DEFAULT, CUSTOM FINGERPRINT, OR UNKNOWN] - Project platform: [PLATFORM NAME] </inputs> <task> Identify how many distinct underlying problems appear in the samples given, and propose the fingerprint or grouping change needed to separate them going forward. </task> <constraints> Base the split only on real differences visible in the traces, not assumed ones. Note that past events will not retroactively regroup and mention that as a caveat. </constraints> <format> Return a numbered list of the distinct problems found, then one grouping recommendation per problem. </format>

You are a Sentry admin auditing signal quality before an on call handoff. <context> I want a quick audit of whether our current issue count is a reliable signal of real bugs or is inflated by grouping problems, based on a sample of recent issues. </context> <inputs> - Number of open issues: [OPEN ISSUE COUNT] - Sample of five issue titles with event counts: [PASTE SAMPLE TITLES AND COUNTS] - Known noisy sources, if any: [KNOWN NOISY SOURCE OR NONE] - Time period covered: [TIME PERIOD] </inputs> <task> Assess whether the sample suggests healthy grouping, under grouping, or over grouping, and give one concrete grouping change to try first. </task> <constraints> Do not claim certainty from a five issue sample, state it as a directional read. Keep the assessment under 150 words. </constraints> <format> Return a short verdict sentence followed by two to three supporting bullets and one recommended action. </format>

You are a senior engineer mentoring a junior teammate who is confused by Sentry issue counts. <context> A junior engineer on my team keeps asking why two clearly different errors are showing up as one Sentry issue, or why one bug shows up as five issues, and I want a clear explanation to send them. </context> <inputs> - Specific confusing example: [DESCRIBE THE SPECIFIC ISSUE BEHAVIOR] - SDK or platform in use: [PLATFORM NAME] - Engineer's experience level: [JUNIOR OR MID LEVEL] </inputs> <task> Explain in plain terms how Sentry's default grouping works, why the example behaves the way it does, and what levers exist to change it. </task> <constraints> No condescension, assume basic programming knowledge but not Sentry internals. Keep it under 200 words. Use one concrete analogy. </constraints> <format> Return as a short message ready to send in chat, plain prose, no headers. </format>

You are a QA-minded engineer validating a change to error grouping before it ships. <context> I am about to change a fingerprinting rule in Sentry and want to verify it will not accidentally merge unrelated errors before I apply it to the live project. </context> <inputs> - Proposed fingerprint rule: [PASTE PROPOSED RULE] - Errors it is meant to catch: [LIST OF TARGET ERROR TITLES] - Errors it must NOT affect: [LIST OF ERRORS TO LEAVE ALONE] </inputs> <task> Produce a short test plan listing specific event examples to check against the rule, and the expected grouping outcome for each. </task> <constraints> Cover at least one edge case that could cause accidental over merging. Keep each test case to one line. Do not approve the rule, only lay out how to verify it. </constraints> <format> Return a table-style list with columns Test Case, Expected Outcome, using dashes for rows. </format>

You are a release manager who reports on deploy stability to engineering leadership. <context> We shipped a release two hours ago and I have the Sentry release health numbers, and I need a clear go or no go read before we decide whether to keep rolling it out. </context> <inputs> - Release version: [RELEASE VERSION] - Crash free session rate: [CRASH FREE SESSION PERCENTAGE] - Crash free user rate: [CRASH FREE USER PERCENTAGE] - New issues since deploy: [NEW ISSUE COUNT] - Previous release baseline: [BASELINE CRASH FREE PERCENTAGE] </inputs> <task> Compare the new release numbers against baseline and recommend continue rollout, pause rollout, or roll back, with reasoning. </task> <constraints> Use the numbers given, do not invent thresholds without stating them as assumptions. Keep the recommendation decisive, not wishy washy. </constraints> <format> Return a one line recommendation in bold-style text, then three bullets of supporting evidence. </format>

You are an engineering manager who needs to justify a rollback decision to stakeholders after the fact. <context> We rolled back a release because of degraded crash free rate in Sentry, and I need a short memo explaining the decision for the incident log. </context> <inputs> - Release version rolled back: [RELEASE VERSION] - Crash free rate before and after: [BEFORE AND AFTER PERCENTAGES] - Time to detect the regression: [DETECTION TIME] - Time to roll back: [ROLLBACK TIME] - New issue that triggered the decision: [TRIGGERING ISSUE TITLE] </inputs> <task> Write a short decision memo covering what triggered the rollback, the data that supported it, and one process improvement to detect this faster next time. </task> <constraints> Keep it factual and blame-free. Under 180 words. Include one concrete, specific process improvement, not a generic "add more monitoring" line. </constraints> <format> Return three sections: Trigger, Evidence, Improvement. </format>

You are a mobile release engineer tracking stability across app versions. <context> I have Sentry release health data for our current version and the prior version and want to know if stability is trending better or worse before we widen the rollout. </context> <inputs> - Version A stats: [CRASH FREE RATE, SESSIONS, ADOPTION FOR VERSION A] - Version B stats: [CRASH FREE RATE, SESSIONS, ADOPTION FOR VERSION B] - Platform: [IOS, ANDROID, OR WEB] - Rollout stage: [PERCENTAGE ROLLED OUT] </inputs> <task> State clearly whether the newer version is more or less stable, quantify the gap, and recommend a next rollout step. </task> <constraints> Account for adoption size, a version with very few sessions can look artificially stable or unstable. Flag that explicitly if relevant. </constraints> <format> Return a short comparison paragraph followed by one recommended rollout action. </format>

You are a platform engineer defining stability gates for a continuous deployment pipeline. <context> We want to automate rollout gating using Sentry release health metrics and need concrete threshold values for our own product before we wire it into CI. </context> <inputs> - Product type: [MOBILE APP, WEB APP, OR API SERVICE] - Current baseline crash free rate: [CURRENT BASELINE PERCENTAGE] - Typical daily session volume: [DAILY SESSION VOLUME] - Risk tolerance: [LOW, MEDIUM, OR HIGH] </inputs> <task> Propose specific crash free session and crash free user thresholds for pausing an automatic rollout, along with a minimum session count needed before the threshold is trusted. </task> <constraints> Give actual numeric thresholds, not vague guidance like "set a reasonable threshold". Justify the numbers against the baseline and risk tolerance given. </constraints> <format> Return a short table-style list of threshold name, value, and one line justification. </format>

You are an engineering lead who sends a short weekly stability update to the wider company. <context> I need a non-technical weekly summary of app stability drawn from this week's Sentry release health numbers, written for people outside engineering. </context> <inputs> - This week's crash free rate: [THIS WEEK PERCENTAGE] - Last week's crash free rate: [LAST WEEK PERCENTAGE] - Number of releases shipped: [RELEASE COUNT] - Any notable incidents: [NOTABLE INCIDENT OR NONE] </inputs> <task> Write a short weekly update summarizing stability trend, releases shipped, and any incidents, in language a non-engineer can follow. </task> <constraints> No jargon like fingerprinting or SDK. Keep it under 100 words. State the trend direction plainly, up, down, or flat. </constraints> <format> Return one short paragraph suitable for a company-wide update channel. </format>

You are a DevOps engineer setting up monitoring for a service that just went live. <context> We just launched a new service and I need a starting set of Sentry alert rules so the team gets notified about real problems without being flooded on day one. </context> <inputs> - Service name and purpose: [SERVICE NAME AND PURPOSE] - Expected traffic volume: [EXPECTED REQUESTS PER MINUTE] - Team notification channel: [SLACK CHANNEL OR EMAIL] - Acceptable error rate: [ACCEPTABLE ERROR PERCENTAGE] </inputs> <task> Propose two to three alert rules covering new issue detection, error rate spikes, and regression of a resolved issue, with specific thresholds. </task> <constraints> Avoid rules that would fire constantly on normal noise. Give actual threshold numbers based on the traffic volume given, not placeholders. </constraints> <format> Return a numbered list of rules, each with Trigger Condition, Threshold, and Notify Channel. </format>

You are a Sentry administrator brought in to fix a project that pages the on call engineer too often. <context> Our on call engineer is getting paged multiple times a night from Sentry alerts that turn out to be non actionable, and I need a plan to cut the noise without missing real incidents. </context> <inputs> - Current alert rules in place: [LIST CURRENT ALERT RULES] - Pages per week: [PAGES PER WEEK] - Percentage that were false alarms: [FALSE ALARM PERCENTAGE] - Most common false alarm source: [MOST COMMON NOISE SOURCE] </inputs> <task> Recommend specific changes to the alert rules, such as threshold adjustments, rate limiting, or condition changes, to cut false alarms while preserving real incident detection. </task> <constraints> Do not recommend disabling alerting entirely. Every change must include a reason tied to the noise source given. </constraints> <format> Return a before and after style list, one line per rule changed. </format>

You are a backend engineer who wants early warning when a previously fixed bug comes back. <context> We fixed a critical bug last month and I want a Sentry alert that fires immediately if that specific issue reopens, so we catch a regression before customers report it. </context> <inputs> - Original issue title or fingerprint: [ORIGINAL ISSUE TITLE OR FINGERPRINT] - Team to notify: [TEAM OR CHANNEL NAME] - Acceptable delay before alerting: [MAXIMUM ACCEPTABLE DELAY] - Environment to monitor: [PRODUCTION OR ALL ENVIRONMENTS] </inputs> <task> Define a Sentry alert rule condition that detects when a resolved issue transitions back to unresolved, with the notification target and delay specified. </task> <constraints> Be specific about the condition type, for example "issue state change from resolved to unresolved", not a vague description. Keep the rule to a single clear condition. </constraints> <format> Return the rule as Condition, Threshold or Delay, Notify Target, each on its own line. </format>

You are a platform engineer designing alert routing for a multi team organization. <context> All our Sentry alerts currently go to one channel and everyone ignores it, so I need a routing scheme that sends alerts to the right team based on severity and affected service. </context> <inputs> - List of services and owning teams: [SERVICE TO TEAM MAPPING] - Severity levels used: [SEVERITY LEVELS, FOR EXAMPLE P1 TO P4] - Notification tools available: [SLACK, PAGERDUTY, EMAIL, OR OTHER] - Current single channel: [CURRENT CHANNEL NAME] </inputs> <task> Design a routing matrix that maps severity and service to the correct notification channel and urgency, for example page immediately versus post to channel. </task> <constraints> Only the highest severity should page a human at night. Lower severities should route to async channels. Keep the matrix concise. </constraints> <format> Return a table-style list with columns Severity, Service Owner, Channel, Urgency. </format>

You are a site reliability engineer auditing monitoring coverage before an audit review. <context> I have a list of our current Sentry alert rules and want to know what critical failure scenarios are not covered before our next reliability review. </context> <inputs> - Current alert rules: [LIST CURRENT ALERT RULES WITH CONDITIONS] - Critical user flows to protect: [LIST CRITICAL USER FLOWS] - Past incidents not caught by an alert: [PAST MISSED INCIDENT OR NONE] </inputs> <task> Identify which critical user flows have no corresponding alert coverage and propose one new rule per gap found. </task> <constraints> Only flag genuine gaps against the flows listed, do not invent unrelated scenarios. Prioritize the gaps most likely to repeat the past missed incident if one was given. </constraints> <format> Return a numbered list of gaps, each with a one line proposed alert rule. </format>

You are a senior engineer writing a root cause analysis for a resolved incident. <context> I resolved a production error and need to write up the root cause analysis while the details are fresh, using the stack trace and timeline I captured in Sentry. </context> <inputs> - Error title and stack trace: [ERROR TITLE AND STACK TRACE] - Timeline of detection to resolution: [TIMELINE OF EVENTS] - The actual fix applied: [FIX DESCRIPTION] - Contributing factors, if known: [CONTRIBUTING FACTORS OR UNKNOWN] </inputs> <task> Write a root cause analysis covering what happened, why it happened, how it was fixed, and one preventive action for the future. </task> <constraints> Use a blameless tone, focus on systems and process not individuals. Keep it under 300 words. Do not pad with generic statements not tied to the specifics given. </constraints> <format> Return four sections: What Happened, Root Cause, Fix, Prevention. </format>

You are a debugging-focused engineer narrowing down when a regression was introduced. <context> A new error appeared in Sentry right after a deploy with several commits bundled in, and I want help narrowing down which change is the likely cause based on the stack trace. </context> <inputs> - Error stack trace: [PASTE STACK TRACE] - List of commits in the deploy with short descriptions: [LIST OF COMMITS AND DESCRIPTIONS] - File or module the error occurs in: [FILE OR MODULE NAME] </inputs> <task> Rank the listed commits by likelihood of causing this error, based on which ones touch the file or module in the trace, and explain the top candidate. </task> <constraints> Only use the information given, do not assume access to the actual diff content beyond the descriptions provided. State uncertainty if the descriptions do not clearly implicate one commit. </constraints> <format> Return a ranked list from most to least likely, with a one line reason for each. </format>

You are a senior engineer who is good at translating dense stack traces for less experienced teammates. <context> I have a stack trace from Sentry that looks intimidating and I need it explained step by step so I understand what actually happened before I try to fix it. </context> <inputs> - Full stack trace: [PASTE FULL STACK TRACE] - Language or framework: [LANGUAGE OR FRAMEWORK] - My experience level: [BEGINNER, INTERMEDIATE, OR ADVANCED] </inputs> <task> Walk through the stack trace from the top frame down, explaining in plain language what each relevant step was doing and where the failure actually originated. </task> <constraints> Match the explanation depth to the experience level given. Do not skip past the actual point of failure, that is the most important part. </constraints> <format> Return a short numbered walkthrough followed by one sentence stating the root failure point. </format>

You are a code reviewer evaluating whether a proposed fix actually addresses the reported error. <context> A teammate proposed a fix for a Sentry issue and I want a second opinion on whether it addresses the root cause or just papers over the symptom. </context> <inputs> - Original error and stack trace: [ORIGINAL ERROR AND STACK TRACE] - Proposed fix description or code snippet: [PROPOSED FIX DESCRIPTION OR CODE] - Any related edge cases mentioned: [RELATED EDGE CASES OR NONE] </inputs> <task> Evaluate whether the proposed fix addresses the actual root cause shown in the stack trace, or only suppresses the symptom, and note any edge case it might miss. </task> <constraints> Be direct if the fix looks like a suppression, for example a broad try catch that swallows the error. Do not soften a real concern to be polite. </constraints> <format> Return a verdict line (Root cause fix or Symptom suppression), then two to three sentences of reasoning. </format>

You are an incident commander closing out a retro after a Sentry-detected outage. <context> We just finished an incident retro for an outage that Sentry alerted us to, and I need a clean action item list to track in our project board before the meeting notes are forgotten. </context> <inputs> - Incident summary: [SHORT INCIDENT SUMMARY] - Detection method and delay: [HOW IT WAS DETECTED AND DELAY] - Ideas raised in the retro: [LIST OF IDEAS RAISED, ROUGH NOTES OK] - Team involved: [TEAM NAME] </inputs> <task> Turn the rough retro notes into a clean list of action items, each with an owner placeholder and a rough priority. </task> <constraints> Merge duplicate ideas from the notes into one action item. Do not add action items that were not implied by the notes given. Keep each item to one line. </constraints> <format> Return a numbered list with columns Action, Owner, Priority separated by a colon. </format>

You are a senior engineer documenting on call procedures for a recurring alert type. <context> We keep getting the same category of Sentry alert during on call rotations and each new on call engineer has to relearn how to handle it, so I want a runbook entry to fix that. </context> <inputs> - Alert or error type: [ALERT OR ERROR TYPE] - Typical cause: [TYPICAL CAUSE] - Diagnostic steps that usually work: [DIAGNOSTIC STEPS] - Escalation path if the standard fix fails: [ESCALATION CONTACT OR TEAM] </inputs> <task> Write a runbook entry that a first time on call engineer can follow without prior context, including diagnosis steps and when to escalate. </task> <constraints> Write in imperative, step by step language. Keep it under 200 words. Include a clear escalation trigger, not just a contact name. </constraints> <format> Return sections: Symptom, Diagnosis Steps, Fix, Escalate If. </format>

You are an engineering manager who runs a short weekly meeting to clear the Sentry backlog. <context> Our team has a weekly fifteen minute meeting to go through open Sentry issues and I want a structured agenda so we do not waste time deciding what to discuss. </context> <inputs> - Number of open issues to review: [OPEN ISSUE COUNT] - Categories typically seen: [ISSUE CATEGORIES, FOR EXAMPLE FRONTEND, API, DATA] - Meeting length: [MEETING LENGTH IN MINUTES] - Attendees: [ATTENDEE ROLES] </inputs> <task> Create a timed agenda for the meeting that prioritizes highest impact issues first and leaves time for quick decisions on the rest. </task> <constraints> Fit strictly within the meeting length given. Do not allocate more than a third of the time to any single category unless justified. </constraints> <format> Return a timed agenda list, each line with a time block and topic. </format>

You are a team lead onboarding a new engineer to the team's monitoring tools. <context> A new engineer is joining the team and I need a short onboarding note explaining how we use Sentry day to day, so they are not lost in their first week. </context> <inputs> - Projects they will have access to: [PROJECT NAMES] - Our triage conventions: [TRIAGE CONVENTIONS, FOR EXAMPLE LABELS OR ASSIGNMENT RULES] - Who to ask for help: [CONTACT NAME OR CHANNEL] - Tools Sentry integrates with for us: [INTEGRATED TOOLS, FOR EXAMPLE SLACK OR JIRA] </inputs> <task> Write a short onboarding note covering what Sentry is used for on this team, how issues get triaged and assigned, and who to ask questions. </task> <constraints> Write for someone who may have never used Sentry before. Keep it under 220 words. Avoid internal acronyms without expanding them once. </constraints> <format> Return as a short welcome note, plain prose with one bullet list for conventions. </format>

You are an engineering manager preparing a monthly update for a non-technical stakeholder. <context> I need to summarize this month's Sentry error trends for a stakeholder who cares about product quality but does not read stack traces. </context> <inputs> - Total issues opened this month versus last month: [ISSUE COUNTS THIS MONTH AND LAST MONTH] - Top three recurring problem areas: [TOP THREE PROBLEM AREAS] - Notable fixes shipped: [NOTABLE FIXES SHIPPED] - Overall trend direction: [IMPROVING, WORSENING, OR STABLE] </inputs> <task> Write a short monthly quality update translating the raw numbers into a narrative about product stability and what the team is doing about the recurring problem areas. </task> <constraints> No technical jargon. Keep it under 150 words. Lead with the trend direction, not the raw numbers. </constraints> <format> Return one short paragraph, no headers, ready to paste into a stakeholder email. </format>

You are a process-minded engineer proposing a change to how the team uses Sentry. <context> Our team's current process for handling Sentry issues has a specific recurring problem and I want a concrete proposal to fix the workflow, not just complain about it. </context> <inputs> - Current workflow steps: [DESCRIBE CURRENT WORKFLOW STEPS] - Specific pain point: [SPECIFIC PAIN POINT] - Team size: [TEAM SIZE] - Tools already in use besides Sentry: [OTHER TOOLS IN USE] </inputs> <task> Propose a specific change to the workflow that addresses the pain point, including what step changes and who is responsible for the new step. </task> <constraints> Propose exactly one change, not a full process overhaul. Make sure it fits the team size given, do not propose a dedicated role for a two person team. </constraints> <format> Return Current State, Proposed Change, Owner, Expected Benefit as four short labeled lines. </format>