Trace what broke, what changed, and how the fix was confirmed.
Timeline turns selected Sentry issues, alerts, and releases into incident evidence you can connect to code and team discussion. Project selection applies to scheduled history checks; after one matching webhook, later webhook events from another project in the same Sentry installation may also be captured.
Sentry records enter a chronological Timeline and resolve into a cited answer.
Fictional Acme example, not customer data.
Question
What broke after the Acme rollout release?
15:06Release v2.8.0
Release creation captured
15:19ACME-913
Onboarding callback error last seen
Source time 15:19ACME-913
Current status observed: resolved
Chronology
Immutable events keep their source and order.
Cited answer
ACME-913 appeared after release v2.8.0 and is now resolved; the Sentry lifecycle record does not establish when the resolution action occurred.
Citation 1: Release v2.8.0Citation 2: ACME-913 occurrenceCitation 3: ACME-913 status
01/What gets captured
What Timeline keeps, and what stays in Sentry.
Timeline captures
Timeline checks selected Sentry organizations or projects and connects captured issue and release evidence to cited incidents. After it receives a matching webhook, a later webhook from an unselected project in the same Sentry installation may also be captured.
Sentry remains
Sentry remains the monitoring and error-diagnostics system. Timeline does not collect application telemetry on Sentry’s behalf or replace Sentry alerting, traces, performance views, or issue management.
Questions
Ask the operating question, not a search query.
01What broke after yesterday’s deploy?
02Which open issues affected checkout this week?
03What release preceded ACME-913?
04How was the incident resolved, and where is the code change?
Example
Fictional Acme example, not customer data.
An alert becomes a complete incident narrative
ACME-913 opens after release v2.8.0, the team discusses impact, a pull request rolls back the change, and Sentry later reports the issue as resolved.
1
Timeline places the Sentry release and ACME-913 lifecycle evidence beside one another while retaining source occurrence timestamps.
2
Slack and GitHub evidence can fill in impact, rollback choice, and remediation.
3
The final answer cites each system without pretending any one record tells the whole story.
Result
The incident review starts from a sourced Acme chronology instead of manual timestamp matching.
What Timeline saves
What enters the Timeline
01
Issues entering an open lifecycle state
02
The first captured resolved lifecycle transition per issue
03
The first captured ignored lifecycle transition per issue
04
Issue alerts delivered for the remembered Sentry installation, including the project-scope caveat below
05
Release creation activity
06
The first captured deployment activity per Sentry release
Use it with
Better when the silos meet
Incident to code fix
Follow the issue lifecycle through review, CI, and release.
Sentry+GitHub
Incident communication
Connect technical state to the response thread and customer impact.
Sentry+Slack
Affected operations
Relate an incident to delivery records or customer work in flight.
Sentry+Monday.com
Setup and privacy
Setup overview
01Connect Sentry using a confidential server-side OAuth application.
02Choose individual projects to scope reconciliation or an organization for all accessible projects there; review the installation-webhook limitation before treating a project choice as a strict webhook boundary.
03Have a Timeline team admin activate the shared sources.
04Configure the signed Sentry integration webhook for issue, alert, and release delivery. Daily reconciliation can recover release creation and issue state only when a newer occurrence advances the polling cursor; it cannot recover webhook-only alerts or deployment records.
Permissions and privacy
Timeline requests org:read, project:read, event:read, event:admin, and team:read.
A confidential OAuth app with a client secret is required; the current adapter does not use a PKCE-only public client.
The integration sees only organizations and projects available to the authorizing Sentry account.
Activated project selections scope reconciliation, but the current remembered-installation webhook route does not recheck the organization/project selection on later deliveries.
These credentials are separate from the DSN used to report Timeline’s own application errors.
Limits
Honest limitations
Review these capture and recovery boundaries before connecting your account.
Alert-trigger and release-deployment records are webhook-only. Reconciliation polls issues and release creation, so it cannot recover a missed alert or deployment delivery.
Scheduled Sentry reconciliation runs every 24 hours. Even a recoverable newer occurrence or release creation can remain stale for nearly a day when its webhook is missed.
After the first matching webhook stores a Sentry installation route, later deliveries for another project in that installation bypass project-selection checks and can enter the same Timeline team even when that project was not activated.
A missed resolve or ignore webhook for a quiet issue may not be recovered because issue polling advances from last-seen occurrence time, which a state-only action does not update.
Issue lifecycle webhooks use the issue’s Sentry first-seen or last-seen occurrence time. They do not preserve the later action time when someone resolves or ignores a quiet issue.
Resolved and ignored records use one immutable lifecycle key per issue. If an issue regresses and later resolves or is ignored again, the repeated closed transition does not create a new lifecycle row.
Polling retains lifecycle state for at most 5,000 issue IDs. After an older resolved issue is pruned, a missed regression webhook can be lost because polling may reuse its original immutable open key.
Deployment records also use one immutable deployed key per release. If the same release is deployed again, for example to another environment, the later deployment does not create a new row.
Repeated occurrences of an already-open issue coalesce into the existing lifecycle evidence instead of generating a new Timeline event for every occurrence.
The native connector focuses on issue lifecycle, alerts, and releases; it is not a replacement for Sentry traces, replays, dashboards, or performance analysis.
Timeline does not resolve, ignore, assign, or configure alerts in Sentry through this capture path.
FAQ
Questions, answered
Does Timeline ingest every Sentry event occurrence?+
No. Timeline captures meaningful issue lifecycle and release evidence. Repeated occurrences of an already-open issue reuse the same open lifecycle record rather than creating noise.
Can I connect only selected projects?+
You can choose specific projects to scope reconciliation, or an organization for all accessible projects there. That project choice is not currently a strict webhook boundary: after a matching installation route is remembered, a later delivery from another project in the same Sentry installation can also be admitted.
Is this the same as configuring a Sentry DSN?+
No. The native source uses Sentry OAuth to read selected project history. A DSN is for sending application telemetry to Sentry and is configured separately.
Can Timeline resolve a Sentry issue?+
No. Sentry remains authoritative for issue state and monitoring configuration. Timeline records the lifecycle so it can support cited cross-tool answers.
