Why this needs more than one source
Incident review becomes unreliable when the first plausible code change is treated as the cause. Sentry can show issue lifecycle and release evidence; GitHub can show implementation and delivery activity; Slack can show what responders observed and decided. None of those sources alone completes the causal story.
Chronology narrows the candidate set. Confirmation still requires evidence such as a reproduced failure, a code-level explanation, a rollback or fix followed by recovery, or another explicit validation recorded by the team.
Build the answer step by step.
Each step leaves something concrete to inspect before the next layer adds interpretation.
- 01
Fix the incident anchor
Start with a Sentry issue key, project, and release when available. Set the window wide enough to include the suspected deployment and narrow enough that unrelated work does not dominate retrieval.
Output
One issue-centered investigation window.
- 02
Lay out the Sentry facts
Record the issue state, captured last-seen time, recurrence or resolution state, affected-user or event counts when present, and nearby Sentry releases. Treat these as observability facts, not a first-observation or root-cause conclusion.
Output
A factual captured-observation and lifecycle spine.
- 03
Add delivery evidence
Retrieve GitHub changes in the same window: pull requests, reviews, default-branch commits, releases, and workflow runs. Look for explicit references to the issue, affected component, release version, rollback, or fix.
Output
A bounded set of candidate changes and delivery events.
- 04
Add the response narrative
Bring in the selected Slack thread or channel where responders discussed symptoms, hypotheses, mitigations, owners, and verification. Preserve revisions in understanding rather than rewriting the thread as if the team knew the answer from the start.
Output
A decision and coordination trail.
- 05
Classify every conclusion
Mark links as confirmed, likely, or unknown. “Confirmed” needs explicit support. Temporal proximity alone belongs under “likely” or “unknown,” even when one change looks suspicious.
Output
An incident account with visible epistemic boundaries.
- 06
Close with verification
End the chronology with the mitigation or fix, the delivery event, and the evidence used to confirm recovery. Keep follow-up work separate from the resolved incident state.
Output
A cited handoff or post-incident dossier.
Evidence example
See the evidence path
The example is illustrative. Its purpose is to make the provenance pattern visible, not to imply customer data or a guaranteed conclusion.
Question
What changed before ACME-913 appeared, and what evidence confirms the fix?
Release v2.8.0 containing the migration callback is published.
ACME-913 enters an active issue state after the release.
Responders reproduce the callback failure and choose a rollback.
ACME-913 is observed as resolved after the rollback window.
The release is correlated; the rollback strengthens the case.
ACME-913 appeared after v2.8.0 and was observed as resolved after the rollback window. That sequence supports a likely connection, but the final account still needs code-level evidence before calling the release the confirmed cause. Source citation 01Source citation 02Source citation 03Source citation 04
- 01Release
- 02Detection
- 03Rollback decision
- 04Resolution
Ask a question with clear edges
Try this question
“Build an incident chronology for Sentry issue [issue key] in [project] from [start time] to [end time]. Include Sentry issue and release evidence, nearby GitHub pull requests, default-branch commits, releases, and workflow results, and the selected Slack response discussion. Separate confirmed facts, likely links, and unknowns. Identify detection, mitigation, fix, and recovery evidence. Cite every factual claim.”
A good query fixes the scope, time window, output shape, citation requirement, and treatment of missing or conflicting evidence.
Source roles
What each source contributes
Each source contributes a different part of the answer. Timeline keeps those roles distinct instead of flattening everything into one activity feed.
Sentry
Detection, issue lifecycle, and release anchor
Issue updates, resolved or regressed states, issue counts and affected-user counts when present, and Sentry releases from selected projects.
What to know
Polled issue events use Sentry’s last-seen time when present and do not preserve a separate first-seen timestamp. This evidence does not replace event-level debugging, stack-trace analysis, or reproduction; an issue near a release is correlation, not proof of causation.
GitHub
Change, review, and delivery trail
Pull requests, reviews, review comments, default-branch commits, releases, and workflow runs from selected repositories.
What to know
Native commit polling follows the repository’s default branch. The selected history may also omit feature-branch, infrastructure, configuration, feature-flag, or third-party changes captured nowhere else.
Slack
Human observation and response decisions
Messages and threads from selected incident or engineering channels.
What to know
Responder statements are valuable evidence of what the team believed and did. They are not automatically verified technical facts.
Use a confidence vocabulary the reader can challenge.
Confirmed means the cited evidence directly supports the link: for example, a reproduced failure in the changed code path and recovery after a targeted fix. Likely means several independent signals align but one confirming step is missing. Unknown means the available record cannot distinguish among plausible causes.
This vocabulary makes the dossier useful during the incident and honest afterward. It also exposes the next evidence-gathering step instead of burying uncertainty under polished prose.
What this cannot prove
- 01Timeline organizes captured evidence; it is not an application performance monitor or debugger.
- 02Polled Sentry issues use their captured last-seen time, so the chronology cannot claim a separately preserved first observation.
- 03Temporal proximity between a release and an issue does not establish causality.
- 04GitHub commit polling follows the selected repository’s default branch; other branch commits require pull-request, release, workflow, or discussion evidence.
- 05An incident can involve systems outside the selected Sentry projects, repositories, or Slack channels.
- 06Resolution state can reflect manual handling or a temporary symptom change; verify recovery with the evidence your team trusts.
- 07Sensitive incident channels and private evidence remain subject to the viewer’s visibility rights.
Common follow-up questions
Can Timeline automatically identify the commit that caused an incident?
Not as a guaranteed fact. It can place captured pull requests, default-branch commits, releases, issue activity, and discussion into one cited chronology. A confirmed causal link still needs supporting technical evidence, and uncaptured branch history remains outside that account.
Should every incident have a Slack channel?
No. Use the response surface your team actually uses. If the decision trail lives elsewhere and is not captured, the dossier should say that the coordination evidence is incomplete.
What belongs in the final incident account?
Detection, impact evidence that is actually available, the changing hypotheses, mitigation, confirmed or likely cause, fix, recovery evidence, and separately listed follow-up work. Every factual claim should remain traceable to a source.
Related walkthroughs
Try it on one real question
Reconstruct one incident without erasing uncertainty.
Connect one Sentry project, its repository, and the response channel. Start with an incident your team already understands, then compare the dossier with the original evidence.
Build an incident timeline