CoNote
GitLabCoNote

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

GitLab knows every push, pipeline, and release — but it’s buried in the project, where only engineers ever look. CoNote logs each deploy onto a shared timeline, beside the campaigns and config changes from the same day.

Start your logbookSee how it works
GitLabpublished a change
Your timelineToday

Released v2.4.0 to production (main → 3a7f2c1)

GitLab· 09:41

Spring sale — daily budget raised to $450

Google Ads· 10:12

Finding your history

Your GitLab deployment history: the long way, and the CoNote way

The manual way · inside GitLab

Where to find it today

It’s all there — if you go digging:

  1. 1

    Open the project in GitLab

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

  2. 2

    Open Deployments → Environments

    Under Deployments, the Environments view shows what’s deployed where, with the commit and the time each deploy went live.

  3. 3

    Check the pipelines

    Under Build → Pipelines, every CI/CD run is listed with its status and trigger — the deploy jobs live here.

  4. 4

    Browse the Releases page

    Under Deploy → Releases, every tagged release is listed with its notes, the commit, and the date it shipped.

  5. 5

    Stitch it together across projects yourself

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

The CoNote way

Where you find it instead

Sign in to GitLab once. After that it’s seconds:

  1. 1

    Open your CoNote timeline

    Every deploy is waiting — no project access, no pipeline-speak, readable by anyone.

  2. 2

    Jump to the day it moved

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

  3. 3

    See it beside everything else

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

Start your logbook

Sound familiar?

GitLab’s history is perfect — for engineers.

#incidentsFriday, 14:05
NW

Nadja14:05

Error rate tripled since 14:00. Did a pipeline deploy something?
TB

Tom14:08

Maybe — a pipeline ran around lunch. Which project though?
NW

Nadja14:10

Which project, which commit? We have a few behind checkout.
TB

Tom14:14

Checking Environments and pipelines on each…

Project by project, across environments and pipelines.

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

  • One project at a time — no single view across projects
  • Deploys split across Environments, Pipelines, and Releases
  • Locked in the project, where marketing and leadership never look
  • Never lined up against the campaign or config change from the same day

With GitLab connected, the deploy is already on the timeline — “Released v2.4.0 to production” at 09:41 — sitting right beside the spike, readable by anyone, on one page.

How it works

Sign in once. Then it logs itself.

  1. 01

    Sign in to GitLab

    One read-only sign-in, then pick your projects. No keys to copy, no SDK, no pipeline rewrite, no engineering sprint. CoNote can never write to your code.

  2. 02

    Every deploy logs itself

    From then on, each release and production deploy lands on the timeline with a readable title — “Released v2.4.0 to production”. You can also import the last months of history when you connect.

  3. 03

    Read it in context

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

What lands on your timeline

  • Releases and production deploys — project, branch, and commit
  • The pipeline or release that shipped it
  • A readable title and the moment it went live

In your week

What teams will use it for.

Side by side

Native history vs. your logbook.

See pipelines, releases, and deploys

GitLab history

In the project

CoNote

On your timeline

Readable by marketing and leadership

GitLab history

Needs project access

CoNote

Team-wide, plain language

Lined up against campaigns, config, incidents

GitLab history

GitLab only

CoNote

Side by side

One view across every project

GitLab history

One project at a time

CoNote

All in one place

Deploys in one place, not three views

GitLab history

Environments + pipelines + releases

CoNote

One timeline

Setup

GitLab history

Built in

CoNote

One read-only sign-in

On the timeline

The deploy in context.

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

Tuesday, June 9

  • Released v2.4.0 to production (main → 3a7f2c1)

    GitLab· 09:41

  • Spring sale — daily budget raised to $450

    Google Ads· 10:12

  • Checkout error rate tripled

    Uptime· 11:30

Questions

GitLab deploy tracking, answered.

Under Deployments → Environments you can see what’s deployed where with the commit and time; Build → Pipelines lists every CI/CD run; and Deploy → Releases shows each tagged release with its notes and date. Each project keeps these separately.

Yes. When you connect you choose how far back to go — 30 days, 3 months, a year, or 3 years — and CoNote imports that history into the timeline. You can also start from today if you’d rather.

No. You sign in to GitLab once and pick your projects — there is nothing to copy and nothing to change in your pipelines. CoNote gets read-only access and can never write to your code.

No. By default it logs releases and deployments — what actually shipped — so the timeline stays a record of what reached users. Merged merge requests, pushes, and failed pipelines are switches you can turn on if you want them.

Each release and production deploy as a plain-language entry — for example “Released v2.4.0 to production (main → 3a7f2c1)” — with the time it happened. CoNote never reads or stores your source code.

GitLab’s history lives in the project, split across Environments, Pipelines, and Releases, where only people with access ever look. CoNote puts your deploys on one shared timeline next to campaigns, config changes, and incidents.

Only your team. Every entry is scoped to your team, and connecting GitLab does not expose your project 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