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 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 2 alternatives. 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.

Silencing a noisy Datadog monitor during investigation

When a known issue is firing repeated pages and a fix is in flight, the engineer mutes the specific Datadog monitor scope for a fixed 30-minute window. The mute reason links the active PagerDuty incident, never widens to the whole monitor and never runs indefinitely.

Tags

datadogmutemonitor-noisescopingauto-expiry

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 known issue is firing repeated pages on the same Datadog monitor and a fix is already in flight, the engineer mutes the specific monitor scope (rather than editing the monitor configuration) for a fixed 30 minute window, adding a mute reason that links the active PagerDuty incident. They never mute indefinitely and they never widen the mute scope to the whole monitor.

Reasoning

PagerDuty deduplicates new alerts onto an existing acknowledged incident only briefly, after which a new page is created. During a known issue with a fix in flight, the second and third pages add no information and wake the secondary unnecessarily. Muting the specific scope (service:api-gateway env:prod) for a fixed 30 minutes prevents the noise but is short enough that if the fix has not landed in time the mute auto-expires and the next breach pages as expected. Editing the monitor itself rather than using the Mute action is the dangerous shortcut, because changes to monitor configuration are easy to forget to undo and silently degrade the team's coverage.

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 Datadog monitor is firing repeated pages onto an active PagerDuty incident, the cause is understood and a fix is in flight to be deployed within the next 30 minutes.

Outcome

The Datadog monitor is muted for a 30 minute window scoped to the affected service and environment, with a mute reason linking the active PagerDuty incident, and will automatically un-mute if the fix has not landed in time.

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 noisy monitor's detail page, click 'Mute Monitor' in the top right.

Use the Mute button on the monitor detail page rather than editing the monitor's settings. The Mute button is designed to expire automatically. Edits to the monitor itself are easy to forget and silently degrade the team's alert coverage long after the incident is over.

Expected: A mute dialog opens with fields for scope, duration and reason.

Datadog

Set the scope to the specific service and environment, not All scopes.

The default scope is everything the monitor watches, which usually includes staging, dev or other environments that share the monitor query. Type in the targeted scope tags exactly. Example: service:api-gateway env:prod. This keeps the staging signal alive even while production is muted.

Expected: The scope field shows the targeted tags rather than 'All'.

Datadog

Set the duration to 30 minutes.

Never mute indefinitely. The 30 minute floor is long enough to ship the fix and verify it, short enough that an unfixed regression will page again. If the fix needs longer, re-mute when the first window expires rather than extending up front. The act of re-muting is what keeps the team honest about whether the fix is actually progressing.

Expected: The duration is set to 30 minutes and an end time is shown.

Datadog

Type a mute reason that includes the PagerDuty incident ID.

Example: 'Muting for PD-PT4ZXKR, fix in flight via api-gateway #4901.' The PD ID gives whoever opens this monitor next an audit trail back to the incident. Without it, they will see only that the monitor is muted with no indication of why or for how long the issue is known.

Expected: The mute reason field contains the PD incident ID and a one line summary.

Datadog

Click Confirm to apply the mute.

Verify the monitor's status changes to Muted in the top right and that the muted scope is listed below the monitor name. If the mute did not register the monitor will continue to fire pages, which is the failure mode this step is guarding against.

Expected: The monitor shows Muted status with the scope and the auto-expiry time visible.

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

Triaging a page from the linked Datadog monitor Acknowledging a PagerDuty page

Often next

Correlating a Datadog spike with a recent deploy

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.

Muted api-gateway prod monitor for 30m, linked PD-PT4ZXKR

Silenced checkout-service env:prod scope, fix in flight

Re-muted billing-worker monitor after first 30m window expired

Set 30m mute on payments-service monitor with PD-Q9HK22N reason

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 14 times across 4 connections
Applications	Datadog, PagerDuty
First seen	11 Feb 2026, 16:33
Last seen	4 May 2026, 20:17

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