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 will log each deploy onto a shared timeline, beside the campaigns and config changes from the same day.

Start your logbook — freeSee 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: today, and once CoNote is live

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 · coming soon

Where you’ll find it once it’s live

Connect GitLab once. After that it’ll be seconds:

  1. 1

    Open your CoNote timeline

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

  2. 2

    Jump to the day it moved

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

  3. 3

    See it beside everything else

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

Start your logbook — free

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 number 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

Once GitLab is connected, the deploy will already be 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

Connect once. Then it’ll log itself.

  1. 01

    Add a project webhook

    Point a GitLab webhook at CoNote — no SDK, no pipeline rewrite, no engineering sprint.

  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” — the moment it happens.

  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

Add a project webhook

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.

Not yet — it’s coming soon. You can start your CoNote logbook now and connect the tools that are already live; we’ll switch GitLab on automatically the day it ships.

Only once, briefly. Connecting GitLab will be adding a project webhook — no SDK and no changes to your pipelines.

It logs releases and production deploys — what actually shipped — not every CI run, so the timeline stays a record of what reached users.

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 will put 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 won’t 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