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 Datadog and GitHub, 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 happens when a case looks like this pattern but does not quite fit?

The connections shown on this page link to related patterns that may match the case better. The agent can follow those edges to find a closer fit.

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.

Correlating a Datadog spike with a recent deploy

The engineer pivots from the Datadog monitor to the affected service's APM page and lines the spike up against the deployment markers. They capture the previous and current release tags spanning the spike and prepare the GitHub compare URL between them.

Tags

datadoggithubdeployment-markersrelease-tagscorrelation

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

The engineer pivots from the Datadog monitor to the affected service's APM page, lines up the spike start time against the deployment markers panel and notes the deployed version tag closest to the spike. They then open the matching service repository in GitHub and go to the Releases page rather than the Pull Requests list, identify the previous and current release tags spanning the spike, then construct or follow the compare URL between them.

Reasoning

Deployment markers in Datadog are populated by the same CI pipeline that creates GitHub releases, so the version on the marker is the literal git tag in the repository. Lining up the spike start to within a 5 minute window of a deploy marker eliminates the 'is it the deploy?' question on its own, before any PR reading. Going via Releases rather than Pull Requests is the key shortcut because the merged PR list contains everything ever merged including reverts and dependabot, while Releases only contains what actually shipped, which is the only set that could have caused a production change.

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 triaged a Datadog monitor and seen a deployment marker close to the spike start time, and needs to confirm that the deploy is the cause and identify the released version range.

Outcome

The engineer has the previous and current release tags on the affected service, knows the deployment time to the minute and has the GitHub compare URL between the two tags ready to inspect.

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.

Datadog

On the APM service page, locate the deployment markers panel below the latency graph.

The panel lists every deploy in the time range with its version tag, the duration since the previous deploy and the change in error rate attributed to that deploy. Sort by time descending so the most recent deploys are at the top.

Expected: The deployment markers panel shows a list of deploys, each labelled with its version tag and deploy time.

Datadog

Identify the deploy whose time falls within 5 minutes before the spike start.

Allow a 5 minute buffer in both directions. APM aggregates in 1 minute buckets, CDN and edge cache TTL adds 1 to 4 minutes of further delay and rolling deploys take 1 to 3 minutes to reach all instances. A deploy marker that lands 4 minutes before the spike is still the prime suspect.

Expected: You have a single deploy marker selected, with a version tag and a timestamp.

Datadog

Copy the version tag from the deploy marker.

The version tag is usually a short SHA prefix or a date-stamped semver style tag (v2026.05.06.1, 8a3f1cd, release-2026-05-06). It is the literal git tag created by the CI pipeline at deploy time, not a branch name.

Expected: The version tag is on the clipboard and visible in your scratch note.

GitHub

Open the affected service's repository and click 'Releases' in the right hand sidebar.

Use Releases not Pull Requests. The Pull Requests list contains everything ever merged including reverts, dependabot updates and feature flag toggles. Releases only contains what actually shipped, which is the only set that could have caused a production change.

Expected: The Releases page opens listing the most recent releases in reverse chronological order.

GitHub

Locate the release tag matching the version from the Datadog marker.

If the version is a SHA prefix, search the page with ⌘F. If it is a semver tag, the most recent two releases are usually the right pair regardless. Note the previous release tag immediately above your suspect tag, this is the comparison baseline.

Expected: You have identified two release tags: the suspect deploy and the release immediately before it.

GitHub

Construct or follow the compare URL between the two release tags.

GitHub releases have a 'Compare' link on each release that compares to the previous tag. If the link is missing, use github.com/<org>/<repo>/compare/<previous-tag>...<suspect-tag>. The triple-dot syntax is wrong here, use the double-dot to get the actual commit set in the second tag.

Expected: The GitHub compare view opens showing the merged PRs and commits between the two release tags.

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.

Often previous

Triaging a page from the linked Datadog monitor Silencing a noisy Datadog monitor during investigation

Often next

Identifying the suspect PR with GitHub Compare

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.

Lined up api-gateway 5xx spike against deploy marker v2026.05.06.2

Datadog deploy marker for checkout-service matches release-2026-04-30-3

Compare URL: api-gateway/compare/v2026.05.05.1...v2026.05.06.2

Confirmed billing-worker spike correlates with deploy 8a3f1cd

payments-service: deploy marker 6 min before spike, within buffer

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 41 times across 5 connections
Applications	Datadog, GitHub
First seen	25 Jan 2026, 15:38
Last seen	5 May 2026, 17:14

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