Ambera
Start free
For founders shipping with AI

See what breaks.Get the fix. Measure it.

AI wrote your app faster than anyone could read it, so Forge watches what it does. Your app sends its events, logs and errors. When a count crosses a threshold you can read, Forge opens an issue with the evidence and proposes the change. After you ship, it shows what changed, in counts you can check.

Start free

Six strikes

What the smithy does that the hammer cannot.

Each strike below is a shipped surface, shown on its own screen. Counts say what they are counted over, and a source sits under every line.

  1. Strike 01 · The anvil — where a strike leaves a mark

    Name the journeys your users must finish. Forge counts who gets through.

    Sign-up, checkout, the first thing a new account does: your app sends its events with your tracking key, and Forge counts every journey day by day. When the share that gets through falls past a threshold, an issue opens, its window, baseline and minimum volume written beside it.

    forge.ambera.app/signal/ledgerline/issues
    One row of the Issues place, in the “In progress” lane: “Journey completion changed: Sign-up”, page /signup, awaiting release. On its right the figure, 43 %, under it −20 points · was 63 %, and a line of the last 14 days that steps down a week ago. Its sentence: 119 of 280 (43 %) completed in 2026-10-19 to 2026-10-25, against 175 of 280 (63 %) in 2026-10-12 to 2026-10-18; −20 points. Under it: 119 of 280 (43 %) people completed · Sign-up · journey completion falling · effort half a day, if the validation lives in one form · opened Oct 23, 2026 · last seen Oct 25, 2026. The pointer rests on the title.

    One row of the shipped Issues place over fixture rows: a journey’s figure, its last 14 days, the detector’s sentence.

  2. Strike 02 · The bellows — the air that reaches the fire

    Who clicked from your site into your product, and who got there.

    Your site marks each click toward your product, and your app reports who arrived. For the rest, Forge shows what came next: an error, staying on the site, or nothing at all. When nothing came, it says it cannot tell a page that failed to load from a closed tab.

    forge.ambera.app/signal/ledgerline
    The Overview’s zone “From the site to the product”, last 7 days, to yesterday, 2026-10-19 to 2026-10-25, with the pointer on “Where they went”. Who clicked from your site into your product, and what your app sent about them in the next 30 minutes. Three figures: 412 Clicked, each visitor counted once a day; 269 Arrived, 65 % of the clicks, in red −7.6 points against 2026-10-12 to 2026-10-18; 143 No arrival seen, 35 % of the clicks, none reported within 30 minutes of the click. A bar of what followed each click, and the counts: Arrived in the product 251 (61 %); Arrived, then an error 9 (2 %); Arrived, then a server error 9 (2 %); An error, never arrived 37 (9 %); Stayed on the site, never arrived 61 (15 %); Nothing received after the click 45 (11 %). Then: most frequent error after a click with no arrival, TypeError: Cannot read properties of undefined (reading ‘email’), from the app, followed 31 clicks, 24 with no arrival. Last: 6 clicks by signed-in visitors are not followed: their id is never put in a link.

    The shipped Overview zone over fixture rows: clicked, arrived, no arrival seen, and what followed each click.

  3. Strike 03 · The slag — what is skimmed off the metal

    Bots are counted apart, by the rule that caught each one.

    Crawlers and headless browsers run your pages too. Forge leaves a session out of your numbers when its browser names itself a bot or a headless browser, or when it opens 20 pages within 60 seconds, and shows how many each rule caught. The rest have no bot sign; Forge never calls them human.

    forge.ambera.app/signal/ledgerline
    The Overview’s fold “Bots left out”: 385 sessions · Declared bot 318 · Too fast for a person 67. Last 7 days, today included: 385 sessions met a bot rule and are left out of every figure here. 2,980 showed no bot sign and are counted. A bot that declares nothing and behaves like a visitor cannot be told from one, so Forge never calls a session human. Then one row per rule: Declared bot 318, the user agent names a crawler or a headless browser, matched against the public isbot list, the user agent itself not kept; Automated browser, not read: it needs @ambera/forge-tracking 0.4.0 or later in the browser; Too fast for a person 67, 20 page views or more within 60 seconds in one session. Rules v2.

    The shipped Overview fold over fixture rows: each rule and the sessions it caught, and one Forge cannot read yet.

  4. Strike 04 · The forge — the tools laid out

    The spec from the evidence, in your agent’s hands.

    What to change and how you will know it worked, drafted from the stored rows. A number the evidence does not hold is marked, not believed. For your agent hands it to Claude Code or Cursor — Forge writes nothing to your repository.

    forge.ambera.app/signal/ledgerline/issues/issue-2
    The work spec card. Its head: Bug fix, v1, and on the right two buttons, “For your agent” with the pointer on it and “Copy as Markdown”. The target behaviour: “A valid address passes the sign-up form, and completion returns to where it was.” Acceptance criteria, two items: an address with a plus sign passes; completion is back above 60 %. Under them, in amber, “In no stored count: Completion is back above 60 % (60)”. Then a folded line, “Scope, tests, risks and files”.

    The shipped spec card over fixture rows: the target, the criteria, the number in no stored count, the hand-off.

  5. Strike 05 · Tempering — counts that can fall

    Did the release change the number? Forge counts it.

    Your tracker sends the release with every event, so Forge knows the moment a version reached production. It compares the seven days before with the seven days after, under a plan written before anything shipped, and states what it saw: improvement, no change, or regression. Never “the fix worked”, because before-and-after is an observation, not proof.

    forge.ambera.app/signal/ledgerline/outcomes
    One row of the Outcomes place, under “Read”. It leads with the release, 4f0a3c1, production · Oct 18, 5:00 PM, with the pointer on it, and the badge Regression. Then two figures, before 0.3 % → after 1 %, +225 %. The title “Error frequency changed: TypeError: Cannot read properties of undefined (reading ’email’)”; the plan, 7 days before the release against 7 after · production; the windows, after 2026-10-19 to 2026-10-25 against 2026-10-11 to 2026-10-17, the release day in neither; and the sentence: 91 of 9,800 (1 %) in the after-window, against 28 of 9,800 (0.3 %) before; +225 % relative; observed regression. A before-and-after comparison is an observation, not proof the change caused it.

    One row of the shipped Outcomes place: the release it measures, before and after, read as a regression.

  6. Strike 06 · The ring — how the metal sounds

    A week later, the numbers say what moved.

    Events, errors and sessions against the week before, each in the colour of its side — more sessions green, more errors red, and errors also per thousand sessions, so a busy week is not read as a worse one. A week Forge does not fully hold is a sentence, never a zero.

    forge.ambera.app/signal/ledgerline
    The arrival strip of the Overview, four figures. Events 31,204, last 7 days, under it in green +3,250 · +12 % vs the week before and a line of the last 14 days stepping up, with the pointer on it. Errors 57, 3 groups, top: TypeError: Cannot read properties of undefined; under it in red +33 · +174 % vs the week before, then 7.4 → 18.1 per 1,000 sessions, week to yesterday, and a red line stepping up beside Open issues. Sessions 2,980, from 1,640 people, last 7 days, in green +310 · +12 % vs the week before and a green line. Last activity last week, an event · production.

    The shipped Overview strip over fixture rows: the week against the week before.

Start free

Each picture is one row or box of the product, no more: all five from its own design harness over fixture rows, every count computed by the shipped math.

Beside Sentry and PostHog

One release. One week.Three answers.

A release goes out. In the week after, one error on /signup triples and sign-up completion falls by a fifth. Here is what each one tells you — in its own shape, at its own moment — and where it stops.

18 Oct
the release goes out

4f0a3c1 · production · read from the rows your app sends

2891
events of one error on /signup

the 7 days after the release, against the 7 before

63 %43 %
sign-ups completed

119 of 280, against 175 of 280 the week before

  1. Sentryminute 1

    An alert, the moment the error is new.

    New issue · TypeError: Cannot read properties of undefined (reading ’email’) · 91 events this week

    Then — The stack trace, the release it first appeared in, a suggested fix as a pull request. Mark it resolved; it reopens if the error returns.

    Stops at the pull request. It does not say that sign-up completion fell with the error, or by how much against the week before.

    You bring the alert rule and its threshold.

  2. PostHogwhen you look

    A chart, when you open it.

    Sign-up funnel · 43 % completed · last 7 days · a replay of one person who dropped

    Then — An alert, if you set one on that insight. An experiment, if you put the fix behind a feature flag and split your users.

    Stops at the chart, or at an experiment you design. It does not say which release moved the number, or whether a plain release moved it back.

    You bring the funnel, the alert, the flag and the experiment.

  3. Forgeday 1 → day 8

    A sentence with its denominator — and a second one after the release.

    Day 1 · the issue opens

    Journey completion changed · Sign-up: 119 of 280 (43 %) completed in 2026-10-19 to 2026-10-25, against 175 of 280 (63 %) in 2026-10-12 to 2026-10-18; −20 points · threshold 5 · minimum 50 · productionErrors on the same page: 77 from /signup in those 7 days, against 7 in the 7 before.

    7 days — Your decision. A spec with the plan the outcome will be measured by, written before anything ships. The release, read from the rows your app sends — nobody marks it.

    Day 8 · Forge comes back

    RegressionTypeError (reading ’email’): 91 of 9,800 (1 %) in 2026-10-19 to 2026-10-25, against 28 of 9,800 (0.3 %) in 2026-10-11 to 2026-10-17; +225 % relative; observed regression.A before-and-after comparison is an observation, not proof the change caused it.

    Comes back with the second sentence, and says beside it what it is.

    You bring the decision.

Keep both. Forge is the one that comes back.

Forge beside SentryForge beside PostHogHow a release is measured

Start free

Bring the hammer. The smithy is lit.

Google, GitHub or an email. 1 product free, no card, no credits: add the snippet to your app, and the counts start with its first row.

Start freeSee the pricing