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, 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.

Triaging a page from the linked Datadog monitor

After acknowledging a page, the engineer follows the linked Datadog monitor and starts triage on its detail page. They expand the time range, read the actual error messages and toggle deployment markers before deciding whether the issue is a code change, an upstream failure or a traffic event.

Tags

datadogtriagelogs-sampledeployment-markersinvestigation

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

After acknowledging a PagerDuty page, the engineer follows the linked Datadog monitor in the incident detail and starts triage on the monitor's detail page. They expand the time range from the default 15 minutes to 1 hour, switch to the Logs Sample tab to read the actual error messages, then toggle the deployment markers overlay before deciding whether the issue is a code change, an upstream failure or a traffic event.

Reasoning

The metric graph alone tells the engineer that something broke but rarely why. The Logs Sample tab on a Datadog monitor surfaces representative log lines from the failing scope, which usually contains the error class, the affected endpoint and the upstream service if any. Expanding to a 1 hour window shows whether the metric was already trending unusually before the threshold breach, which separates genuine new incidents from slow burns. Deployment markers on the chart are the fastest visual confirmation that a recent ship is the culprit, before any GitHub work begins.

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

A PagerDuty page has been acknowledged and the engineer has opened the linked Datadog monitor in a new tab.

Outcome

The engineer has identified whether the issue is a code change, an upstream dependency, an infrastructure event or organic traffic, and has captured the failing service name, the dominant error class and the approximate spike start time ready to correlate against deploys.

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

Land on the monitor detail page from the PagerDuty link.

Confirm the monitor name and the alert message match the PagerDuty incident. If the link drops you on the monitors list rather than the detail page, the PagerDuty link has expired or been edited and you should re-open the incident detail page.

Expected: The Datadog monitor detail page is open with the alert state at the top and the metric graph scoped to a 15 minute window centred on the breach.

Datadog

Click the time range selector and switch from 15m to 1h.

The 15 minute view is too narrow to see the baseline. Looking at the hour before the spike reveals slow climbs, deploy adjacent dips and recovery patterns from earlier flaps. If the spike is genuinely sudden in the 1h view, that on its own narrows the cause to a discrete event such as a deploy or a config change.

Expected: The metric graph re-renders with the breach roughly in the middle, the baseline visible to the left and any recovery to the right.

Datadog

Click the 'Logs Sample' tab below the metric graph.

The Logs Sample is filtered to the same scope as the monitor (service, env, tags) and the same time window. Read the top three log lines, not just the most recent. Repeating error messages with the same trace pattern point to a deterministic bug, varied messages with different traces point to an upstream or infrastructure issue.

Expected: A list of 10 to 50 log lines from the failing scope is displayed, each one linked to its trace and host.

Datadog

Toggle the Deployment Markers overlay using the small flag icon above the metric graph.

Deployment markers come from the deployment_id and version tags emitted by the CI pipeline, so they line up with GitHub releases. If a marker sits within 5 minutes of the spike start the deploy is the prime suspect, but allow a 5 minute buffer because metrics aggregate in 1 minute buckets and CDN cache TTL adds further delay.

Expected: Vertical markers appear on the metric graph at deployment times, each tagged with the version that shipped.

Datadog

Open the affected service's APM page in a new tab using the 'View Service' link in the monitor footer.

Use the View Service link rather than searching from the APM index. The link preserves the time range and environment filters so the latency, error rate and throughput panels are pre-scoped to the incident.

Expected: The APM service page opens in a new tab showing the four golden signals over the same 1 hour window.

Datadog

Note the failing service name, the dominant error class and the spike start time in a scratch note for the next step.

These three facts are what the GitHub correlation step needs. Capturing them now prevents bouncing back to Datadog while reading PR diffs.

Expected: You have the service name, the error class and a UTC timestamp of the spike start ready to use.

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

Acknowledging a PagerDuty page Escalating a page to the secondary on-call

Often next

Correlating a Datadog spike with a recent deploy

Alternative to

Silencing a noisy Datadog monitor during investigation

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.

Triaged PD-PT4ZXKR: api-gateway 5xx spike, logs sample showed retry storm

Datadog: expanded api-gateway monitor to 1h, deploy marker visible

Read logs sample on checkout-service monitor for PT5MN8L

Triaged billing-worker timeout monitor, deploy marker at 14:32

Toggled deploy markers on payments-service monitor, no marker near spike

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 58 times across 5 connections
Applications	Datadog
First seen	23 Jan 2026, 11:02
Last seen	6 May 2026, 22:48

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