GitHub integration
Install the CoNote app on GitHub and your deployments, releases and merged pull requests land on the timeline, with the history you already have.
The GitHub integration records what your team ships, so a change in your numbers sits next to the release that might have caused it. You install a small app on GitHub, pick which repositories it may read, and CoNote does the rest. There are no links or keys to copy anywhere.
What lands on your timeline
| Event | What you see | On by default |
|---|---|---|
| Deployment | "Deployed shop to production (main → 3a7f2c1)" | Yes |
| Release | "Released shop v2.1.0" with the release notes | Yes |
| Merged pull request | "Merged: New checkout flow (#412)" | No |
| Push | "Pushed to shop (main → 3a7f2c1)" | No |
| Failed deployment or build | An Incident note | No |
A deployment is the moment something actually went live, which is usually what you want to line up against your metrics. A push is the moment code was merged, which can be hours or days earlier. That is why deployments are on by default and pushes are not.
Every note links back to GitHub, and each event is recorded once even if GitHub sends it twice.
Setting it up
Name it and connect
In Integrations, choose GitHub. Give it a name and press Connect GitHub. That is everything CoNote asks before the connection exists.
Install the app on GitHub
GitHub asks which account and which repositories CoNote may read. Pick All repositories or select individual ones. CoNote only ever reads: it can never write to your code.
Choose what to log
You land back in CoNote, and now every setting is filled from your own account: your repositories and the environments they deploy to. Pick what you want, choose how much history to import, and save. The first notes appear within a few minutes.
Changing your mind later is easy. Which repositories CoNote may read is managed on GitHub, under your organisation's Settings → GitHub Apps. Everything else lives on this page.
Importing your history
Webhooks only ever tell CoNote what happens from now on, so a fresh connection would start with an empty timeline. When you connect, CoNote reads your past deployments, releases and merged pull requests instead, going back as far as you choose: 30 days, three months, a year or three years.
Two things are worth knowing. Large imports can push you past your plan's note limit; the extra notes are still collected, but stay locked until you upgrade.
And the depth you choose does not apply to everything. Deployments, releases and merged pull requests are permanent records in GitHub, so those go back as far as you ask. Pushes are not: GitHub only keeps them for about 90 days, so they are never imported at all. If you switch pushes on, they start appearing from that moment forward.
Narrowing what gets logged
Repositories. Pick from the ones you granted on GitHub. Selecting none logs all of them.
Environments. CoNote reads the environments your repositories actually deploy to and offers
them as a list, so there is nothing to type. Selecting none logs all of them, previews included. If
your setup creates a preview deployment per pull request, select just production.
Branches. Empty means the repository's default branch. You can also name patterns, for example
main, release/*.
Paths. In a monorepo, apps/web/** limits pushes to the part you actually own.
Seats and billing
GitHub counts as one seat, no matter how many repositories you log. Setting it up is free: the seat is only charged once the connection has proven it works. Until you finish the install on GitHub, the integration reads Not connected and costs nothing.
When something stops working
If someone uninstalls the app or removes CoNote's access to a repository, the integration switches to Needs attention and tells you what happened. Re-installing restores it, and nothing already on your timeline is lost.