When does an AI agent use this pattern?

When the trigger described above matches the situation the agent is handling. The agent queries FusedFrames at runtime, this pattern is returned and the agent follows the recorded reasoning and steps to reach the recorded outcome.

How were the steps captured?

By the desktop app on the machine of someone who actually does this work. It records clicks, keystrokes, copy and paste, drag and drop, selected text and screen regions across GitHub and PagerDuty, then groups them into the meaningful steps shown above.

Where does the reasoning come from?

From the operator. When the desktop app sees a decision the action alone cannot explain, it asks why in the moment. The operator's answer is recorded and becomes the reasoning attached to the pattern, so the AI agent gets the thinking and not just the steps.

What if my team handles this differently?

Capture how your team actually does it. The desktop app records what your operator does on your tools and the web app distills that into a pattern shaped by your team. Each team's library reflects their own approach rather than the example shown here.

What if a case looks like this pattern but does not quite fit?

The pattern is linked to 1 alternative. The agent can follow the connections shown on this page to a related pattern that matches the case more closely.

How does my AI agent actually call this pattern?

Through the read-only REST API or the npm CLI. Create an API key in the dashboard, choose whether it accesses all libraries or specific ones and have your agent query at runtime. The response is structured JSON ready for tool use.

Is the data shown on this page from a live customer?

No. Example libraries on this site are illustrative. Patterns in your own account are built from your team's captured actions and stay private to your workspace.

How do I build a pattern like this for my team?

Install the desktop app on the machine of the person who already does this work, ask them to handle a real case end to end, then distill the captured action into a pattern in the web app. The pattern you end up with mirrors how your team actually operates.

Shipping a forward fix instead of rolling back

When a clean revert is not possible (a migration ran, the suspect PR sits on top of unrelated work or revert fails CI), the engineer ships a minimal forward fix instead. They get a thumbs-up from the secondary on-call posted on the PagerDuty status update and record the agreement to ship forward on the incident timeline.

Tags

githubhotfixforward-fixmigrationminimal-diff

Lets your agent filter to the right pattern

Categories and tags scope the retrieval set, so your agent receives only the patterns relevant to the task instead of scanning the full library.

What and why

The observed behaviour and the reasoning behind it.

Behaviour

When a clean revert is not possible (a database migration has already run, the suspect PR sits on top of unrelated changes that should not be reverted or the revert itself fails CI), the engineer branches a small fix from main, names it hotfix/<incident-id>, makes the minimum change needed to restore service, gets a thumbs up from the secondary on-call posted on the PagerDuty status update rather than a formal GitHub review, and merges with the [hotfix] label so the deploy pipeline runs the abridged test suite.

Reasoning

Some changes cannot be undone by a code revert. Migrations leave the schema changed, feature flag flips have already affected user state and PRs that batched under the same release cannot be cleanly separated. In those cases a forward fix is faster and lower risk than a complex revert. The agreement on the PagerDuty status update rather than a formal GitHub review is deliberate. A formal review pulls in two or three engineers, each of whom needs the situational read, while the secondary on-call already has it from the incident timeline and can make a judgement in 90 seconds. Naming the branch hotfix/<incident-id> ties commits back to the post-mortem automatically.

Gives your agent an operator's reasoning

Behaviour records the action; reasoning records the rationale. Your agent applies both to handle cases that diverge from the captured examples.

Cause and effect

What initiates this pattern and what it produces.

Trigger

The engineer has identified the cause of an incident but a clean revert is impossible or unsafe due to a migration, batched releases or a CI failure on the revert PR.

Outcome

A small forward fix is merged and deployed under a hotfix branch, the original suspect PR is updated with a comment explaining the forward fix and the PagerDuty incident timeline records the agreement to ship forward rather than revert.

Tells your agent when to act and what to verify

Your agent stays within the scope set by the trigger and outcome, so it doesn't extend beyond the work or finish before the outcome is met.

Standard operating procedure

Step-by-step instructions to reproduce this pattern.

GitHub

From the affected service's repository on the default branch, create a new branch named hotfix/<incident-id>.

Use the PagerDuty incident ID as the suffix, for example hotfix/PT4ZXKR. This makes the branch self-documenting. Anyone reading git log months later can trace the change to the original incident in PagerDuty without needing the post-mortem.

Expected: A new branch hotfix/<incident-id> is checked out locally or via the GitHub web editor.

GitHub

Make the minimum change needed to restore service.

Resist the temptation to fix related issues, refactor the touched function or add tests for the broader area. Every additional line is new risk on a hotfix that will skip the full test suite. If the smallest possible fix is two lines, ship two lines and open a follow up PR for the rest.

Expected: The branch contains a tightly scoped diff, ideally under 30 lines of production code.

PagerDuty

Post a status update on the incident timeline asking the secondary on-call to thumbs up the forward fix.

Example: 'Migration ran on api-gateway #4892, going forward fix. Two line patch on the retry policy default. Priya, ack to ship?' The secondary already has the situational read on the incident. Routing through PagerDuty rather than a GitHub review thread keeps the conversation in the audit trail and saves the secondary from a tab change.

Expected: The PagerDuty timeline carries the request and the secondary's acknowledgement in reply.

GitHub

Open the hotfix PR with a [hotfix] title prefix and the [hotfix] label applied.

The label is what the deploy pipeline reads to decide whether to use the abridged test suite. The prefix is the human signal for reviewers and dashboard filters. The body of the PR should link the original suspect PR, the PagerDuty incident and explain in one or two sentences why a revert was not viable.

Expected: The hotfix PR is open with the [hotfix] label applied and CI is running the abridged suite.

GitHub

Merge the hotfix PR once CI is green.

Use Squash for hotfixes rather than Merge. The branch typically has multiple small commits from rapid iteration during the incident and a single squashed commit on main is easier to read in the post-mortem.

Expected: The hotfix PR is merged to the default branch and the deploy pipeline has started.

GitHub

Add a comment to the original suspect PR explaining the forward fix.

Reference the hotfix PR by number, name the change and indicate whether the original PR is now considered fixed or still requires a follow up. Example: 'Forward fix shipped in #4910 (PD-PT4ZXKR), retry policy default reverted to 3. Will follow up to make this a config rather than a constant.'

Expected: The original PR has a comment linking the forward fix and indicating whether further work is expected.

Hands your agent your team's exact steps

Your agent executes the documented procedure in order, against the applications named at each step, producing consistent output across human and agent runs.

Book a demo

Related patterns

How this pattern connects to other patterns in the library.

Alternative to

Rolling back by reverting the merge commit

Often next

Verifying a rollback restored service in Datadog

Lets your agent confirm the match and its scope

Alternative patterns let your agent compare candidates and select the closest match. Previous and next patterns define position in the workflow, so the agent operates within the scope of this one.

Supporting actions

Actions that provide evidence for this pattern.

Hotfix #4910 on api-gateway, migration meant clean revert wasn't viable

Forward fix on checkout-service hotfix/PT5MN8L, 2-line patch

Skipped revert on billing-worker, shipped hotfix #3820 instead

Asked Priya for thumbs up in PD before hotfix, 90 sec turnaround

Shows your agent the evidence behind the pattern

Each pattern is derived from captured action sequences. Your agent can reference the source actions to verify any field, so nothing it acts on is authored by hand or hallucinated.

Metadata

Timestamps and identifiers.

Evidence	Observed 8 times across 3 connections
Applications	GitHub, PagerDuty
First seen	19 Feb 2026, 22:51
Last seen	22 Apr 2026, 11:04

Helps your agent rank patterns by confidence

Action count and last-seen timestamp weight each pattern by frequency and recency, so your agent selects the highest-scoring match rather than the first returned.

Questions

Frequently asked questions

Book a demo View all examples

Speak to the founder

Get a demo. Watch a live capture, then an AI agent query the result.

Ask anything. Pricing, security or integrating with your stack.

No purchase obligation

Book a call

Start capturing

Record in minutes. Install once and work as normal.

Plug AI agents in. One API call from any AI agent stack.

Refund on unused credits if you cancel