Engineering

From the alert to a reviewable fix in one run

Most of an on-call shift isn't engineering. It is reading the trace, hunting for the commit, checking whether the last deploy is to blame, updating the ticket, and telling the channel. Kentron runs that whole stretch across your systems and hands you a diff to review.

What this replaces

Twenty tabs open at 2am to answer one question: what changed?

Book DemoSee the receipt
Priya Shah2:11 PM

@Receipt checkout is throwing 500s. What shipped in the last hour, and is it the cause?

ReceiptApp2:13 PM

Very likely. The Sentry issue started at 14:04, two minutes after Vercel deploy dpl_9f2. That deploy carried PR #2288, which changed the Stripe idempotency key. Draft revert PR #2291 is open for your review.

Receiptrcp_8c41

Three jobs Engineering stops doing by hand

Each one is a single run across the systems you already use, with a policy gate before anything changes and a receipt for every call.

  1. 01

    Root-cause an alert before anyone joins the call

    You ask

    @Receipt checkout error rate tripled at 14:00. What changed?

    • Sentry
    • Datadog
    • Vercel
    • GitHub
    • Slack

    What Kentron does

    1. Reads the Sentry issue, groups the stack traces, and finds when it first appeared
    2. Lines that window up against Vercel deploys, Datadog metrics, and merged GitHub PRs
    3. Names the suspect commit, quotes the changed lines, and opens a revert PR for review
    4. Posts a timeline to the incident channel with a link to everything it read

    What it leaves behind

    Every API response from Sentry, Vercel, and GitHub is stored as returned, hashed, and chained. The postmortem cites evidence, not memory.

  2. 02

    Clear the flaky-test backlog on a schedule

    You ask

    @Receipt every Monday, find last week's intermittent test failures and file them.

    • GitHub
    • Linear
    • Slack

    What Kentron does

    1. Scans CI runs for tests that both passed and failed on the same commit
    2. Ranks them by how many merges they blocked, not by raw failure count
    3. Opens one Linear issue per flake with the failing seed, run links, and a likely owner from git blame
    4. Closes each issue once the test has stayed green for fourteen days

    What it leaves behind

    Each issue it opens, edits, or closes is its own receipt, so nobody has to take it on faith that the grooming was honest.

  3. 03

    Check the Terraform plan before anyone applies it

    You ask

    @Receipt before the release, diff the Terraform plan against prod and flag anything destructive.

    • Terraform Cloud
    • AWS
    • GitHub
    • Slack

    What Kentron does

    1. Pulls the pending plan from Terraform Cloud and reads the resource-level changes
    2. Compares it with live AWS state for anything being replaced or deleted
    3. Flags each destructive change with its blast radius and the ticket that asked for it
    4. Holds the apply behind a gate until a named person approves it in Slack

    What it leaves behind

    The approval, the approver, and the plan hash they approved are chained together, so the apply can't drift from what was reviewed.

For Engineering, the proof is the postmortem

Every call Kentron makes is written to a hash-chained receipt with the raw response attached. On call, that turns a guess about what changed into a record you can read, replay, and cite.

  • Postmortems quote the raw Sentry, Vercel, and GitHub responses, not anyone's memory
  • Fixes arrive as draft pull requests, so a person always makes the merge call
  • A Terraform apply is bound to the plan hash a named person approved

Receipt

Checkout 500s, 14:04 incident

rcp_8c41

  1. Read: Sentry

    7d2a…e41c

    Read issue RCP-4471 and its stack traces

  2. Read: Vercel

    b90f…3a72

    Read deploys from 13:00 to 14:10

  3. Read: GitHub

    41ce…d908

    Read PR #2288 and its diff

  4. Wrote: GitHub

    e3b7…60f1

    Opened draft revert PR #2291

  5. Wrote: Slack

    0a5d…9c2e

    Posted the timeline to #incidents

5 calls, chain verified

The tools Engineering usually connects

Any tool you use can be connected. These are where this team tends to start.

  • GitHub
  • Sentry
  • Linear
  • Vercel
  • Datadog
  • Slack
  • AWS
  • Terraform Cloud

Use cases for other teams

Put Kentron on the Engineering backlog

Connect one system, then read the receipts it writes before you connect the next.

Book Demo