| name | analyze-sentry-logs |
| description | Analyze Sentry logs to find real issues, severity mismatches, and missing observability. Only runs when explicitly invoked via /analyze-sentry-logs.
|
| user_invocable | true |
| allowed-tools | Bash, Read, Grep, Glob, Agent |
| disable-model-invocation | true |
Sentry Log Analysis
Analyze Sentry logs for the PodHaven iOS app. This is a logs-only analysis — no Sentry issues, events, crashes, or other data. Focus exclusively on what the logs reveal.
"Sentry logs" here means Sentry's structured logs (ourlogs) — a different source from the device NDJSON files the analyze-logs skill reads. For a single error issue use analyze-sentry-issue; for one user feedback use analyze-sentry-feedback. Those two reuse the shared sentry-cli/ fetch scripts (fetch_sentry_logs.sh, filter_sentry_logs.py) for targeted, user/trace-scoped timelines rather than the bulk pattern triage here.
Arguments
Accepts a time span argument. Examples:
/analyze-sentry-logs 12h — last 12 hours/analyze-sentry-logs 2d — last 2 days/analyze-sentry-logs 1w — last week
If no argument is provided, ask the user what time span they want before proceeding.
Optional second argument: a Sentry logs search query. Use user.id:<uuid> to
scope to one user (PodHaven sets this to the device IDFV). Use trace:<id> when
correlating to a specific error event. The analyze-sentry-issue skill uses
these filters for targeted timelines — this skill uses them for bulk pattern
triage across the whole window.
Environment mismatch (PodHaven): error events often tag environment:testFlight
while structured logs usually tag environment:deployed. Do not filter logs by
the event's environment unless you have confirmed that tag on log rows. Prefer
user.id and optional release.
Prerequisites
Requires the sentry CLI (cli.sentry.dev) and
Sentry auth (sentry auth login). See analyze-sentry-issue prerequisites
for install notes. Do not use the Sentry MCP server.
Step 1: Fetch logs
Run .agents/scripts/sentry-cli/fetch_sentry_logs.sh — it uses
sentry log list and sentry explore under the hood:
bash .agents/scripts/sentry-cli/fetch_sentry_logs.sh <statsPeriod>
bash .agents/scripts/sentry-cli/fetch_sentry_logs.sh 6h \
'user.id:<uuid> severity:[warn,error]'
bash .agents/scripts/sentry-cli/fetch_sentry_logs.sh 1h \
'trace:<trace_id> severity:[warn,error]'
Where <statsPeriod> matches the user's time span (e.g., 10h, 2d, 1w).
To narrow fetched rows to an incident window (used heavily by
analyze-sentry-issue):
python3 .agents/scripts/sentry-cli/filter_sentry_logs.py \
--around-ms <event_epoch_ms> --window-ms 600000 --oneline
This outputs:
/tmp/sentry_logs_detail.json — individual log entries (up to 1000 per fetch)/tmp/sentry_logs_summary.json — aggregated counts grouped by severity + message- A summary table printed to stdout
Present the summary table to the user immediately.
If you need to inspect individual entries (e.g., timestamps, burst patterns), read the detail JSON:
python3 -c "
import json
with open('/tmp/sentry_logs_detail.json') as f:
for row in json.load(f)['data']:
print(f\"{row['timestamp']}\t{row['severity']}\t{row['message'][:120]}\")
"
Step 2: Deep-dive into every log pattern
For every unique log pattern in the summary, find the source code. Use Grep to locate the log message string in *.swift files, then Read the surrounding context (at least 15 lines in each direction).
For each pattern, determine:
- What triggers this log? Read the function it's in. What condition leads here? Trace callers if needed.
- Is this expected or a bug? Is this a normal edge case the code handles gracefully, or does it indicate a real problem the user should know about?
- Is the severity right?
.error: something is broken and needs investigation.warning: something unexpected happened but was handled.info: notable state change, useful context.debug: verbose detail for active debugging only
- Is there enough context in the log message? Look at the local variables available at the log call site. Could you diagnose the root cause from this message alone, or is it missing values that are right there in scope? For example, a guard that logs "value is invalid" should include what the value actually was. Recommend adding specific variables/state to the message string.
- Are related failure modes unlogged? Look at nearby code paths — are there error conditions or edge cases with no logging at all?
- Burst patterns — If the same message fires multiple times within milliseconds, investigate why. Check the detail JSON timestamps to identify bursts. This often reveals a single event triggering multiple redundant log calls.
For logs produced by caughtError() (which uses ErrorKit.isRemarkable() to choose between remarkable: and mundane: severity levels), check whether the error type is correctly classified. isRemarkable should return false for expected errors like cancellation, network timeouts, etc.
For log messages not found in the current codebase, check git log --oneline -10 for recent refactors that may have removed them. Mark these as Stale and skip deep analysis — they'll stop once users update.
Step 3: Classify each pattern
Every log pattern gets exactly one verdict:
- Real issue — The log reveals a bug, data problem, or user-facing degradation. Describe what's wrong and suggest a fix.
- Downgrade to
.X — Fires for an expected/handled condition. Specify current and recommended level, and why.
- Upgrade to
.X — Fires for something more serious than its level suggests. Specify current and recommended level, and why.
- Enrich message — The log fires at the right level but is missing context that's available in scope. Specify what variables/state to add to the message string.
- Add logging — A nearby code path lacks observability. Describe what to add, at what level, and where.
- Fine as-is — Right level, useful signal, sufficient context. Briefly say why.
- Stale — From code no longer in the codebase. Skip.
Report Format
# Sentry Log Analysis — [time span] ([absolute date range in PT])
## Summary
[2-3 sentences: total log count by severity in the time window, overall signal-to-noise assessment]
## Log Patterns
Present every unique log pattern, in descending order of count:
### `[first line of message]`
- **Count:** N | **Severity:** error/warn | **Source:** `File.swift:LINE`
- **Verdict:** Real issue | Downgrade to .X | Upgrade to .X | Add logging | Fine as-is | Stale
- **Analysis:** [What triggers this, why it fires at this frequency, what should change and why.
For "Real issue" verdicts: describe the bug and suggest a fix.
For severity changes: explain what signal is gained or noise removed.
For "Add logging": describe the gap and what to add.]
- **Suggested change:** [Specific code diff if applicable, or "None"]
## Missing Observability
[Code paths found during the deep-dive that should have logging but don't.
Only include concrete gaps — not hypothetical ones.]
[If none: omit this section]
Keep it dense and actionable. Every pattern gets a verdict. No filler.
