Engineering

The bug someone saw at 02:14 is a ticket by 02:15

One on-call thread becomes one ticket, written the way a reviewer wants to read it, filed once and never twice.

On-call intake

File tickets from the on-call channel

Who it is for: Engineering managers and on-call leads whose channel is where bugs are first said out loud, then lost.
What starts it: A thread in the on-call channel you name; On an inbound message

An on-call channel is where bugs are first said out loud, and where they die. The person who saw it was mid-incident. The report is retyped badly two days later, or filed twice from two threads, or filed as "checkout broken" with no steps, or never filed at all because by morning the log line has scrolled away.

This use case turns one thread into one ticket. The ticket carries what happened, the steps the thread established, expected and actual, how often — with the thread's own hedge kept, so "~2% of confirms" stays an estimate rather than becoming a measurement — and the quotes it all came from, each one beside the person who wrote it and the minute they wrote it. It ends with the section most bug reports leave out and most reviewers ask for first: what the thread did not establish. Which client retried. Whether the first attempt succeeded. Whether a customer was charged twice.

It does not decide the owner, the labels or the priority, and it cannot: a draft carrying any of those fields is refused before anything is filed. Scout already proposes all four on every item in a team triage inbox, with a confidence and a reason, and you apply them with one click. Two brains guessing at the same four fields is how a team ends up with two answers and no decision.

Filing once is a database constraint rather than a judgement. One thread has one key — the Slack workspace, the channel and the thread timestamp — and a unique index refuses the second fire, so a message Aestus receives three times files one ticket. A second thread about the same incident is a different question and gets a different answer: the draft may name a possible duplicate only from the tickets this channel has already filed, and a person merges them on the card.

Nothing about the channel is trusted. The step that reads the thread is a model with no tools at all, so a message written to be read by an agent has nothing beside it to reach. The step that files the ticket can create one ticket and link it to another, and can read nothing and send nothing. Anything shaped like a token, a key or a password is stripped out of the thread before the model sees it, and the draft is checked for the same shapes again on the way back. What a hostile message can achieve, stated plainly: a wrong ticket in a triage inbox, which a person then declines.

The ticket lands in your team's inbox, not on your board — a queue a person accepts from. And when the check fails twice, nothing is filed at all. That is the intended default, not a gap: a report nobody can trace reads exactly like one they can, which makes it worse than no report.

What you get

The artifact this use case produces, in the product view you would read it in.

Example — fictional team and data. Not a live run or customer result.

Worked example

ticket-set

Checkout confirm returns 500 when the client retry reuses an idempotency key

Produced by: Run EXAMPLE-OC-01 · one thread read · filed to team triage · demo values

What happened: `POST /api/checkout/confirm` returns 500 on the client retry path. The server log line is `PaymentIntentConfirmError: idempotency_key reused`. Two people saw it independently in #oncall-payments.
Steps the thread established: 4 steps, each one the thread established rather than one a reader would have to guess: Call `POST /api/checkout/confirm`. Let the first attempt time out on the client. The client retries with the same idempotency key. The retry returns 500.
Expected: The retry returns the result of the first confirm, or a deterministic conflict response. Reusing an idempotency key is the retry contract, not an error.
Actual: 500, `PaymentIntentConfirmError: idempotency_key reused`.
How often: Reported in the thread as roughly 2% of confirms, first seen about 01:55. That figure is the thread's own estimate and was not measured in the thread.
Not established in the thread: 4 open questions the thread never settled, which is the section most bug reports leave out and most reviewers ask for first: Which client or SDK version retried. Whether the first attempt actually succeeded server-side. Whether a customer was charged twice. Which deploy introduced it.
Evidence: 3 quotes from 2 different people in #oncall-payments, each copied character for character and kept beside the person and the minute it was written — dana 02:19 "log line: PaymentIntentConfirmError: idempotency_key reused"; raj 02:22 "only on the retry path I think - first attempt is fine, the client retry after a timeout blows up"; dana 02:26 "~2% of confirms. not paging.". The thread permalink is on the ticket.

How it runs

Each step is one node in the workflow graph the interpreter runs. Nothing here is a prompt chain hidden in a route handler.

Workflow steps

01A thread arrives
Aestus checks two things before it spends anything: the thread is in the channel you named, and enough different people have spoken in it. A thread that fails either starts no run at all.
02It decides one thing first
Did a named person say they SAW something break? A question, a feature request, a deploy notice or an alert nobody confirmed is not a bug, and each of those is refused by name.
03It writes the report
What happened, the steps the thread established, expected, actual, how often, what the thread never settled, and the quotes it all came from. The step that reads the thread holds no tools at all.
04It checks its own draft
Nine checks before anything is written: every quote must sit beside the person who wrote it at the time they wrote it, every ticket id must be one Aestus handed over, and nothing shaped like a key or a token may be copied out.
05If the check fails twice, nothing is filed
The run fails and no ticket exists. A wrong ticket costs a reviewer more than a missing one costs the product, so silence is the safe default here.
06The ticket lands in triage
In your team's inbox with the thread link attached, not on your board. Scout proposes the duplicate, the owner, the labels and the priority on the same card, and you accept.

By hand, and on Aestus

The same job, on either side.

By hand
Someone scrolls back through the night and decides what was real.
On Aestus
The thread is read when it happens, and the decision is one sentence you can read later.
By hand
The report is retyped from memory two days later.
On Aestus
The report quotes the thread word for word and links back to it.
By hand
"Checkout broken", with no steps.
On Aestus
Steps, expected, actual, and an explicit list of what the thread did not establish.
By hand
Two people file the same bug from two threads.
On Aestus
One thread files at most one ticket, ever. For a second thread, Scout proposes the duplicate on the card.
By hand
Nobody knows what it cost or whether it was right.
On Aestus
Every run is a record with its cost, and the ticket you accept or decline is the verdict.
By hand
An automation files straight into the backlog and you find out later.
On Aestus
It files into your triage inbox. Nothing becomes a commitment until a person says so.

What Aestus records

Every run is auditable after the fact, which is what makes handing the job over survivable.

The run
Cost, tokens, duration and a failure code if it failed, on the same ledger as every other run in the workspace.
The ticket
With the thread permalink in its description and an On-call intake record attached — a second copy of the report, rendered from the checked draft rather than written again.
The decision not to file
One event per thread Aestus read and left alone, carrying the one-sentence reason. Nothing is posted to the channel for those.

What it connects to

Only the tools this workflow actually uses. Each one has a setup guide.

slackRequired

Questions teams ask

What stops it filing noise?

Four things, cheapest first. The thread must be in the channel you named and carry at least as many different named people as you set — checked before any model runs, so a quiet thread costs nothing. Then it files only when a named person says they saw the behaviour. Then the draft has to pass a written check. Then the ticket lands in triage rather than on your board.

What stops two tickets for one bug?

One thread files once, keyed on the Slack workspace, the channel and the thread timestamp. That key is a database constraint, not a judgement, so a message delivered to Aestus three times still produces one ticket. For a second thread about the same bug, the draft may name a duplicate only from the tickets this channel already filed, and Scout proposes the merge on the triage card.

Does it decide who owns it?

No. It writes the report and nothing else — it cannot emit an owner, a label, a priority or a severity, and a draft that carries one of those fields is refused. Scout proposes all four on the triage card and a person applies them.

Can a message in the channel tell it what to do?

The step that reads the thread is a model with no tools at all, so there is no lever beside the untrusted text to pull. The step that files the ticket can create one ticket and link it, and can read nothing and reach nothing outside Aestus. Anything shaped like a token or a key is removed from the thread before the model sees it.

Which trigger works today?

Aestus cannot yet watch a channel passively; it receives only messages that mention it. Today you point a Slack Workflow Builder step at the use case's webhook when a message is posted, or you run it from the catalog on a thread you paste in. Passive watching is in build.

All use cases How access is governed

Sources

lib/domain/use-cases/file-tickets-from-the-on-call-channel/seed.ts
lib/domain/use-cases/file-tickets-from-the-on-call-channel/draft.ts
lib/domain/use-cases/file-tickets-from-the-on-call-channel/launch.ts
lib/domain/team/triage.ts

Hand over File tickets from the on-call channel.

Tell us how your team does this today and we will set it up with you.

Talk to us

Questions teams ask

What stops it filing noise?

What stops two tickets for one bug?

Does it decide who owns it?

Can a message in the channel tell it what to do?

Which trigger works today?

Sources

lib/domain/use-cases/file-tickets-from-the-on-call-channel/seed.ts

lib/domain/use-cases/file-tickets-from-the-on-call-channel/draft.ts

lib/domain/use-cases/file-tickets-from-the-on-call-channel/launch.ts

lib/domain/team/triage.ts

The bug someone saw at 02:14 is a ticket by 02:15

File tickets from the on-call channel

What you get

Checkout confirm returns 500 when the client retry reuses an idempotency key

How it runs

By hand, and on Aestus

What Aestus records

The run

The ticket

The decision not to file

What it connects to

Questions teams ask

Other use cases

Hand over File tickets from the on-call channel.

The bug someone saw at 02:14 is a ticket by 02:15

File tickets from the on-call channel

What you get

Checkout confirm returns 500 when the client retry reuses an idempotency key

How it runs

By hand, and on Aestus

What Aestus records

The run

The ticket

The decision not to file

What it connects to

Questions teams ask

Other use cases

Hand over File tickets from the on-call channel.