Skip to content

AI changelogs for GitHub, GitLab and Bitbucket teams

Your changelog, written the moment you merge.

Recap watches your repository, reads the diff behind every pull request, merge request and direct commit, and writes a summary a human actually wants to read. No config file. No release script. Nobody assigned to “do the changelog.”

Get started for free

Free credits on signup · Unlimited repositories · No credit card required

acme/platform

main

Thursday, 14 August

  1. Payslip access now checks the requesting employee's own record

    Any authenticated user could previously request a payslip by ID. The controller now authorizes against the signed-in employee before the file is streamed.

    SW swap PR #486 3 files +42 −11

  2. Subscription reminders send in the member's own timezone

    The reminder job was scheduled in UTC. It now resolves each member's stored timezone and queues at 9am local.

    NM nina-m PR #482 7 files +118 −34

  3. Routing and middleware consolidated into feature modules

    push a3f19c2 100 files +420 −541

0

Recent PRs and commits backfilled the second you connect a repo

0

Config files, CI steps or release scripts to maintain

0

Event types watched — PR merges and direct commits

Seconds

From change landing to a published, readable entry

01 — The problem

Every team starts a changelog. Almost none of them finish one.

Write it at release time

Release day is the worst possible moment to reconstruct six weeks of merges from memory.

Ask everyone to update the file

It becomes the one review comment nobody wants to leave, and the entry quietly never lands.

Generate it from commit messages

“fix stuff”, “wip”, and “address review” are not a changelog. They are an apology.

Skip it and answer in Slack

Now the changelog exists — scattered across four threads that nobody can search next quarter.

The work already happened. The record of it just needs someone — or something — to be paying attention when it does.

02 — Watch it happen

Merge. Then look away.

Three things happen without anyone opening a tab. Scroll to run the sequence — or watch the whole thing end to end.

A pull request or commit lands

GitHub, GitLab or Bitbucket fires a webhook the instant the change lands on your default branch. Recap verifies the signature, acknowledges in milliseconds, and queues the work. Direct pushes are picked up too — and a push that is just a PR's merge commit is never logged twice.

Merged

2 seconds ago

POST /webhooks/source-control/…
signature verified
event pull_request.closed or push

Recap reads the actual diff

Not just the title. The queued job pulls the pull request, merge request or commit context, its file list and the patch itself, then hands that context to the model. Oversized diffs are truncated gracefully rather than dropped.

Reading 3 files

app/Http/Controllers/PayslipController.php

+ $this->authorize('view', $payslip);

− $payslip = Payslip::find($id);

+ $payslip = $user->payslips()->findOrFail($id);

tests/Feature/PayslipAccessTest.php

The entry publishes itself

A title and a short summary land on your timeline, grouped by day, credited to the author, stamped with the PR number or commit SHA and diff stats. No draft queue, no approval step, nothing waiting on you.

Payslip access now checks the requesting employee's own record

Any authenticated user could previously request a payslip by ID. The controller now authorizes against the signed-in employee before the file is streamed, with a regression test covering the cross-account case.▍

PR #486 3 files +42 −11 published

03 — What you get

Built for the way merges actually happen.

Written from the diff

The summary comes from the code that changed, not from whatever the commit message happened to say. Context includes PR or merge request details when available, the file list and the patch.

History from minute one

Connecting a five-year-old repository does not give you an empty page. Recent pull requests and commits are summarized immediately, in a single batched call.

Merges and direct pushes

Both are watched. A push that is really a pull request's merge commit is deduplicated, so the same change never appears twice on the timeline.

Diff stats on every entry

Files touched, lines added, lines removed — the shape of a change at a glance, next to the author and the pull request number or commit SHA.

Nothing fails silently

If a provider rate-limits or a summary times out, the entry stays on the timeline marked failed, with the reason and a retry button. You always know what is missing.

Locked down by default

GitHub, GitLab and Bitbucket tokens are encrypted, webhooks are verified per application, and passkeys plus two-factor authentication protect your Recap account.

“What shipped this week?” should take four seconds to answer, not an afternoon of scrolling through pull requests and commit history.

04 — Setup

Three steps, once.

Then you never touch it again.

  1. 1

    Create your account

    Sign up free, then connect GitHub, GitLab or Bitbucket. Recap stores the access token encrypted and uses it only for the repositories you choose.

  2. 2

    Pick a repository

    Choose from your repo list. Recap registers the webhook for you and immediately backfills recent pull requests and commits.

  3. 3

    Keep shipping

    That is the whole setup. Every merge or direct commit from here on writes itself onto the timeline, grouped by day.

05 — Who it's for

The people who keep asking what shipped.

Engineering leads

Run standup without doing archaeology

Open one timeline instead of scrolling the merged tab, commit list and branch names to reverse-engineer four days of work.

Founders & product

Know what shipped without asking

Summaries are written for a reader who was not in the pull request. Check on progress without pulling an engineer out of flow.

Support & customer success

Answer “when did that change?”

A searchable, dated record of behaviour changes, with the pull request number or commit SHA attached when someone needs to go deeper.

06 — Pricing

Pay for summaries, not for seats you don't use.

Every plan includes unlimited repositories. Credits are spent on AI summarization and reset each month — a live merge or commit costs one summary, and a repo's initial backfill is batched into a single call.

Free

0

AI credits per month

  • 1 seat
  • Unlimited repositories
  • Automatic backfill on connect
  • Passkeys & two-factor auth
Get started for free
Most popular

Freelancer

0

AI credits per month

  • 1 seat
  • Unlimited repositories
  • Automatic backfill on connect
  • Passkeys & two-factor auth
Get started for free

Agency

0

AI credits per month

  • 5 seats
  • Unlimited repositories
  • Automatic backfill on connect
  • Passkeys & two-factor auth
Get started for free

07 — Questions

Reasonable objections.

Most of them are about trust, and they should be.

How is this different from generating a changelog from commit messages?

Commit messages describe what a developer typed at 11pm. Recap reads the actual pull request or commit diff — title, description when available, changed files and the patch itself — and writes a summary from what the code does. "fix stuff" becomes a sentence a stakeholder can read.

Do I have to change my workflow?

No. You connect a repository once and keep merging or pushing exactly as you do today. Recap registers a webhook on your repo, listens for pull request, merge request and commit activity on your default branch, and writes an entry each time. There is no config file to commit, no CI step to add, and no release script to run.

Will my changelog be empty when I connect an existing repo?

No. The moment a repository is connected, Recap backfills recent pull requests, merge requests and commits, so your timeline has real history before the first new change lands.

What happens if a summary fails to generate?

Nothing disappears. A failed entry stays visible on the timeline with the reason it failed — a source control API hiccup, a timeout, an exhausted credit balance — and a retry action next to it. Retrying re-runs the summary for that single entry.

How do credits work?

Each plan includes a monthly allowance of AI credits. Credits are consumed by summarization: a live merge or commit costs one summary, and the initial backfill of a repo is summarized in a single batched call rather than one per change. Every plan includes unlimited repositories, and credits reset each month.

What access does Recap need to my code?

You connect GitHub, GitLab or Bitbucket and grant repository access through OAuth or a provider token. The token is stored encrypted and used to read pull request, merge request and commit metadata, plus diffs, and to register the webhook on the repository you pick. Incoming webhook payloads are verified with a secret unique to each application, and requests that fail verification are rejected outright.

Who is the changelog written for?

Your team and the people who ask your team what shipped — engineering leads, founders, support and customer success. Summaries are allowed to carry technical detail, because the reader is internal.

How do I secure my Recap account itself?

Passkeys, two-factor authentication with recovery codes, and password confirmation on sensitive actions are all built in, alongside source control sign-in.

Stop writing changelogs. Start having one.

Connect a repository in under a minute. Recent pull requests and commits will be waiting for you when you land on the dashboard.

Get started for free Log in