A product updates page in Notion, fed by GitHub

Customers want to know what shipped. The team does not want to write the changelog by hand on Friday. Amendary turns each release, or each shipped day, into a short, dated, customer-facing entry on a Notion page you own.

What the page is

A product updates page is a Notion page you pick as the changelog home. Its type is set on the Pages tab, and one or more source repositories feed it. Each repository’s shipped changes become dated entries on that page. A repository feeds at most one page.

Product updates are Notion-only. A GitHub file cannot be a changelog parent. See our own public product updates page, which Amendary grows from its own repository.

What an entry looks like

  • One to three sentences, written for customers. Breaking API or MCP changes and anything that needs a UI update are called out. Internal refactors, tests and tooling are skipped.
  • Never one entry per commit. For commit-triggered updates there is one entry per repository per day (UTC), combining that day’s merged pull requests and direct commits into one note. Releases and tags stay their own entries.
  • Documentation updates and developer-only or test-only capabilities are never published as product news.
  • Each entry records the release or commits it came from.

Grouping is set on the page

You choose how the page grows: one child page per month, one per week, one page per change, or one running page. The setting lives on the page, not on the repository, so several repositories feeding one page are grouped the same way.

If the parent page already holds a changelog you maintain, Amendary appends new entries to it and keeps your layout. Only an empty parent gets the default of one page per month. Period pages use the change’s own date, so a release published in September lands on the September page even if it is processed later.

Past entries are history. Amendary does not go back and rewrite them. If an old entry needs a change, edit it in Notion.

Review or auto-publish

Review mode

The default for new workspaces. Each entry waits in the queue, the list of drafts for your review, under its own product updates section. You publish or dismiss it. The free trial always works this way.

Auto mode

On a paid plan, an owner can let entries publish on their own. The one thing still held is an entry naming a version, path or URL the change does not back up, so a made-up “we shipped X” never goes out.

A grounded entry is one whose every version, path and URL the change itself supports. That is the bar in both modes; review mode just adds a person before publishing.

What it costs

Entries written from shipped changes are covered by the flat subscription. The subscription is never metered, so shipping more does not cost more.

Generating from scratch is different. A backfill reads the repository’s whole history of releases, tags and changes and writes one entry per real change in one run. That spends credits; the estimated number of entries and the credit cost are shown before you confirm. The daily entries and a backfill are independent, and neither uses up the other.

Setup

  1. Connect GitHub, add Notion as a destination from the Pages tab, and share the parent page with the integration.
  2. On Pages, find the page (or add it by link), set its type to Product updates, add the source repositories, and pick the grouping.
  3. On Repos, set each repository’s change trigger: GitHub Releases, tags, a branch, or default-branch commits.
  4. Open the queue when the first entries arrive, and publish or dismiss them.

Where to go next

See your first product update drafted from a real release

Connect GitHub and the docs you already keep in Notion or GitHub. The first check runs on a recent release, so you see a correction with its evidence before you decide anything.

Free for 7 days, no card. You approve every edit. Code is never touched.