CoNote
GitHubCoNote

Your GitHub deployment history, on a timeline the whole company can read.

GitHub knows every push, release, and commit — but it’s buried in the repo, where only engineers ever look. CoNote logs each deploy onto a shared timeline, beside the campaigns and config changes that shipped the same day.

Start your logbook — freeSee how it works
GitHubpublished a change
Your timelineToday

Deployed storefront v2.4.0 (main → 3a7f2c1)

GitHub· 09:41

Spring sale — daily budget raised to $450

Google Ads· 10:12

Finding your history

Your GitHub deployment history: today, and from now on

The manual way · inside GitHub

Where to find it today

It’s all there — if you go digging:

  1. 1

    Open the repository on GitHub

    Pick the repo whose history you need — each one keeps its deploys, releases, and commits entirely separately.

  2. 2

    Open the Deployments view

    On the repository home, click Deployments (or Environments) in the right sidebar for each deploy, its environment, the triggering commit, and timestamp.

  3. 3

    Browse the Releases tab

    Open Releases for every tagged release with its notes, the commit it shipped, and the date it was published.

  4. 4

    Read the commit history

    Open the commits view for every change with its author, message, and SHA; filter by branch or date to narrow it down.

  5. 5

    Stitch it together across repos yourself

    More than one service? Repeat for each repo and reconcile the timestamps by hand — nothing lines deploys up against marketing or analytics.

The CoNote way · one timeline

Where to find it from now on

Connect GitHub once. After that it’s seconds:

  1. 1

    Open your CoNote timeline

    Every deploy is already waiting — no repo access, no commit-speak, readable by anyone.

  2. 2

    Jump to the day it moved

    Scan the day the number shifted; the deploy is stamped there to the minute.

  3. 3

    See it beside everything else

    The deploy sits right next to that day’s campaigns, config changes, and incidents — the cause is obvious.

Start your logbook — free

Sound familiar?

GitHub’s history is perfect — for engineers.

#incidentsFriday, 14:05
NW

Nadja14:05

Error rate tripled since 14:00. Did something ship?
TB

Tom14:08

I think there was a deploy around lunch? Not sure which service.
NW

Nadja14:10

Which repo, which commit? We have three behind the checkout.
TB

Tom14:14

Checking all three now… give me twenty minutes of git log.

Twenty minutes of digging, across three repositories.

It answers “what shipped in this repo?” — never the question the rest of the company has: “what changed across every team around the day the number moved?”

  • One repository at a time — no single view across services
  • Locked in the repo, where marketing, SEO, and leadership never look
  • Never lined up against the campaign or config change from the same day
  • Reads like commits and SHAs, not a record a non-engineer can scan

With CoNote, the deploy is already on the timeline — “Deployed storefront v2.4.0” at 09:41 — sitting right beside the spike, readable by anyone, on one page.

How it works

Connect once. Then it logs itself.

  1. 01

    Paste a webhook URL

    Drop CoNote’s webhook URL into your repository settings — no SDK, no pipeline changes, no engineering sprint.

  2. 02

    Every deploy logs itself

    From then on, each push and release lands on the timeline with a readable title — “Deployed storefront v2.4.0” — the moment it happens.

  3. 03

    Read it in context

    The deploy sits beside that day’s campaigns, GTM changes, and incidents. When a metric moves, you scan one page instead of four tools.

What lands on your timeline

  • Every push and release to the branches you choose
  • The branch and the commit SHA that shipped
  • A readable title like “Deployed storefront v2.4.0”

In your week

What teams actually use it for.

Side by side

Native history vs. your logbook.

See pushes, releases, and deploys

GitHub history

In the repo

CoNote

On your timeline

Readable by marketing, SEO, and leadership

GitHub history

Needs repo access

CoNote

Team-wide, plain language

Lined up against campaigns, config, incidents

GitHub history

GitHub only

CoNote

Side by side

One view across every repository

GitHub history

One repo at a time

CoNote

All in one place

Searchable with business context

GitHub history

Commits and SHAs

CoNote

Search and filter

Setup

GitHub history

Built in

CoNote

Paste a webhook URL

On the timeline

The deploy in context.

A deploy on its own is a SHA. Next to the campaign and the error spike from the same morning, it’s an explanation.

Tuesday, June 9

  • Deployed storefront v2.4.0 (main → 3a7f2c1)

    GitHub· 09:41

  • Spring sale — daily budget raised to $450

    Google Ads· 10:12

  • Checkout error rate tripled

    Uptime· 11:30

Questions

GitHub deploy tracking, answered.

On the repository home, open Deployments (or Environments) in the right sidebar for each deploy and its environment, or the Releases tab for every tagged release with its notes and date. The commits link shows every change with its author and SHA.

Only once, briefly. Connecting GitHub is pasting a webhook URL into the repository settings — no SDK and no changes to your build or pipeline.

It logs pushes and releases to the branches you point it at — your production deploys, not every work-in-progress commit. You decide which events are worth a line on the timeline.

Yes. You add CoNote’s webhook URL in the repository settings, so private repos work exactly like public ones — and your source code is never read or stored.

Each push and release lands as a plain-language entry — for example “Deployed storefront v2.4.0 (main → 3a7f2c1)” — with the time it happened. CoNote only reads the events you send it; it never touches your code.

GitHub’s history lives in the repo, one repository at a time, and only people who can read code ever see it. CoNote puts your deploys on a shared timeline next to campaigns, config changes, and incidents — so the whole team can line a deploy up against the day a metric moved.

Only your team. Every entry is scoped to your team, and connecting GitHub doesn’t expose your repository to anyone outside it.

Keep digging

Track the rest of your stack.

Open the logbook.

Free plan, no card. The next time someone asks “what changed?”, the answer is one search away.

Start your logbook