Connect the plan, review, merge, release, and CI evidence.
Timeline turns selected repository activity into a chronological, citable record. Follow work from issue through review and release without treating a pull request title as the whole story.
Timeline captures selected repository activity as immutable evidence and can map synced issues and pull requests to human-readable work items.
GitHub remains
GitHub continues to host repositories, reviews, checks, releases, access rules, and branch protection. Timeline reads authorized activity; it does not become your code host.
Questions
Ask the operating question, not a search query.
01What did GitHub publish in last week’s releases?
02Which pull requests changed the migration path?
03What was discussed before PR #482 was approved?
04Which CI failures delayed the release?
Example
Fictional Acme example, not customer data.
A release note gains its missing middle
The Acme migration callback begins as planned work, changes during review, passes CI, and appears in a GitHub release. The tag alone cannot explain the verification path.
1
Timeline records PR #482, its review summary, and its review conversation.
2
The merge and CI #1602 show when implementation and verification happened.
3
Release v2.8.0 closes the publication sequence while citations preserve the route back to GitHub.
Result
The release summary reflects review and verification without claiming when or where the change was deployed.
What Timeline saves
What enters the Timeline
01
Pull requests and first-observed snapshots within each lifecycle state
02
Issues and first-observed snapshots within each lifecycle state
03
Issue comments and pull request conversation comments
04
Review summaries and inline review comments
05
Default-branch commits within the initial-history cap, plus observed push activity
06
Releases and GitHub Actions workflow runs
Use it with
Better when the silos meet
Plan versus published
Reconcile Linear issue movement with code, CI, and GitHub release publication.
Linear+GitHub
Incident to fix
Trace a Sentry issue through the pull request and GitHub release tied to remediation.
Sentry+GitHub
Release communication
Pair GitHub release publication with the decisions that preceded it in Slack.
Slack+GitHub
Setup and privacy
Setup overview
01Connect GitHub through the configured GitHub App OAuth flow.
02Choose individual repositories for a fixed scope. Use an organization scope only when the GitHub App installation covers every repository you expect Timeline to sync.
03Have a team admin activate the shared sources.
04Use signed GitHub App webhooks for prompt activity; scheduled reconciliation runs every six hours as a bounded recovery path.
Permissions and privacy
Timeline requests repo and read:org OAuth scopes.
The GitHub App needs read access to Contents, Issues, Pull requests, Actions, and Metadata for the complete record.
Organization expansion follows the connection owner’s OAuth access. Repository sync uses a matching GitHub App installation token when Timeline discovers one, but currently falls back to the broad OAuth token when it cannot match an installation.
OAuth tokens and GitHub App credentials are encrypted at rest.
Limits
Honest limitations
Review these capture and recovery boundaries before connecting your account.
A published GitHub release is publication evidence, not proof of a production deployment. This connector does not ingest GitHub deployment or environment records.
Initial default-branch commit history is capped at 2,000 commits. If a repository has more, older commits are omitted and the current backfill does not resume past that cap.
Other bounded GitHub scans also stop without continuing past 2,000 pull requests per state, 2,000 combined issue-endpoint entries, 2,000 releases or workflow runs per surface, and 2,000 review summaries per pull request. GitHub’s issues endpoint mixes issues and pull requests; Timeline filters PR entries only after fetching, so PRs consume the shared 2,000-entry scan budget and can leave fewer genuine issues. Issue and inline-review comment surfaces use a separate continuation path.
The source picker lists at most 2,000 organizations and the 2,000 most recently updated repositories available to the OAuth user. Older repositories outside that window cannot be chosen as individual fixed-scope sources.
An organization source also expands at most its 2,000 most recently updated repositories. Older repositories beyond that cap are omitted even when the GitHub App installation has all-repository access.
For an organization scope, install the GitHub App for all repositories you expect Timeline to capture. A repository visible to the OAuth user but excluded from a selected-repositories App installation can be selected yet fail to sync.
GitHub App discovery currently inspects only the first 100 installations returned during OAuth. If Timeline cannot match a repository owner to a discovered installation, repository API reads fall back to the connection owner’s broad OAuth token instead of failing closed; an activated organization source can therefore admit OAuth-visible repositories outside the intended App installation boundary.
Scheduled GitHub reconciliation runs every six hours. Without a matching webhook or another targeted sync trigger, recoverable activity can remain stale for nearly six hours.
Commit reconciliation polls the repository default branch. A missed push webhook for commits that exist only on an unmerged non-default branch is not recovered unless those commits later reach the default branch.
Polling retains issue and pull-request lifecycle state for at most 5,000 IDs per map. After an older closed entry is pruned, a missed reopen webhook can be lost because polling may reuse the original immutable open key.
Issue and pull-request records are first-observed snapshots within each lifecycle state. Title, body, assignee, label, or milestone edits that do not change lifecycle state reuse the existing immutable row and do not create new chronology evidence.
Release revisions are keyed by release lifecycle plus a digest of tag, name, and body, not by update time. If release content returns to a previously captured combination, Timeline reuses the earlier immutable row instead of recording the repeated value as new chronology evidence.
Missing pull-request permission can leave PR activity incomplete while other readable repository surfaces continue to sync.
An organization scope is access-aware; private or SAML-protected repositories may require additional GitHub authorization.
Timeline does not push code, merge pull requests, change repository settings, or replace GitHub release controls.
FAQ
Questions, answered
Can I connect only one repository?+
Yes, when it appears in the picker’s 2,000 most recently updated repositories. Older repositories beyond that cap cannot currently be selected individually. Organization selection also expands at most 2,000 recently updated repositories and should be used only when the GitHub App installation covers every repository you expect Timeline to sync.
Does Timeline capture review comments?+
Yes. It captures review summaries, ordinary pull request conversation comments, and inline review comments when the GitHub App has the required access.
Does Timeline modify GitHub?+
No. The native integration is a read and capture path for cited evidence. GitHub remains authoritative for code, reviews, checks, and releases.
How quickly does activity appear?+
Configured signed webhooks carry normal PR, issue, release, workflow, and push activity promptly. Scheduled reconciliation runs every six hours across repository surfaces, but commit recovery polls only the default branch, so non-default-branch-only pushes rely on webhook delivery.
