Sentry + Datadog + PagerDuty Integration Playbook

What You Will Learn

• Connect Oatty to a natural-language agent via MCP.
• Import OpenAPI catalogs and configure auth headers.
• Prompt the agent to draft safe, reviewable workflows for integration setup.
• Confirm provider availability and required identifiers.
• Validate PagerDuty service + Events API v2 integration details.
• Create and verify Datadog → PagerDuty service-key mappings.
• Validate notification handles safely and keep monitors in draft mode.
• Roll back cleanly when needed.

Purpose

This playbook documents a repeatable integration style and a safe procedure to configure, verify, and roll back:

Sentry -> PagerDuty

Datadog -> PagerDuty

Sentry -> Datadog (provider availability check)

This version is written for a natural-language workflow: you prompt an MCP-connected agent, the agent drafts commands/workflows in Oatty, and you explicitly review and run.

Use this when onboarding a new environment or re-running setup after service renames, org changes, or key rotation.

This guide assumes prior account setup, access to credentials (PAT or Bearer token) and the ability to set these tokens securely in Oatty

tip MCP setup: If your agent is not connected yet, set up the MCP server first: `/docs/learn/mcp-http-server`.

How to Use This Guide (Goal-Oriented, NL-First)

This guide is designed to communicate goals rather than define one exact path. Use prompts to express intent; let the agent adapt commands/workflows for your environment.

Prompt patterns are non-deterministic by design: they define expected outcomes and guardrails, not fixed command sequences for every account/org. Always verify output from your agent before execution.

Keep these safety rules in mind: explicit approval before writes, never provide secrets to your agent, rollback readiness before risky changes, and pass/fail confirmation after each phase.

expected Different environments can use different commands while still achieving on the same integration outcomes.

tip If command IDs or workflow IDs differ, require your agent to perform discovery first, then continue only after the agent maps equivalent actions for your environment.

Prompt Patterns: Prompt -> Expected Agent Actions

Use these prompt patterns when working with an MCP-connected agent. Adjust the prompts as needed to achieve the desired outcome.

Each pattern includes a prompt block plus expected actions so review remains predictable and auditable.

tip Workflow IDs differ by environment. Ask the agent to discover available workflows first, or view them in Oatty's TUI workflow view.

expected Each prompt should result in accurate, valid workflows, clear gates, and auditable outcomes.

advanced Ask your agent to use value providers for inputs to your workflow. This will data to be retrieved remotely as options to workflow input when running it manually.

Pattern 1: Import Catalogs and Verify Headers

Use this pattern at the start of a new environment onboarding to automate the catalog import process.

Prompt:
Import APIs for Sentry, Datadog, and PagerDuty into Oatty using their OpenAPI schemas (URLs preferred). Stub the necessary headers (for example, Authorization), then pause for me to enter access tokens in Oatty's TUI. Use https://raw.githubusercontent.com/DataDog/datadog-api-client-go/master/.generator/schemas/v2/openapi.yaml for DataDog

expected Expected agent actions: import published OpenAPI catalogs, places blank values for any required headers, and pauses for token entry.

tip The Oatty TUI logs agent actions in real time. Use `Ctrl+L` in Oatty to view the logs panel and follow along.

Pattern 2: Configure Mapping with Review Gates

Use this pattern when you want the agent to begin the process of discovery and planning end-to-end.

Prompt:
Configure Sentry -> Datadog -> PagerDuty mapping using workflows. Ask me for any missing inputs or actions needed to proceed that cannot be accomplished via Oatty.

expected Expected agent actions: verify connectivity, discover commands, inspect current state, draft preflight/config workflows for review, map outputs, and report success/failure with rollback status.

Pattern 3: Non-Paging Datadog -> PagerDuty Validation

Use this pattern to validate routing safely without sending pages.

Prompt:
Create a non-paging validation path for Datadog -> PagerDuty using workflows.

expected Expected agent actions: run the environment's validation workflow, confirm monitor is draft, confirm PagerDuty handle in monitor message, and return monitor ID with a safe publish/test plan.

Pattern 4: Preflight Stop-Before-Write Gate

Use this pattern to force hard stop behavior before any write path.

Prompt:
Before any write action, run preflight workflow and stop if PagerDuty service is missing or Datadog auth fails.

expected Expected agent actions: execute preflight, enforce gate conditions, and halt on failure with concrete remediation steps instead of attempting writes.

Pattern 5: Re-Run Verification with Checklist

Use this pattern after setup changes or before release windows.

Prompt:
Re-run full integration verification and produce a pass/fail checklist.

expected Expected agent actions: run preflight plus Sentry/PagerDuty audit workflows and emit a checklist for Datadog mapping, Sentry PagerDuty wiring, draft monitor presence, and unresolved risks.

Pattern 6: Idempotent Configure-Then-Verify

Use this pattern when existing configuration may already be present.

Prompt:
Use workflows to configure and then validate; if configuration already exists, skip creation and only verify.

expected Expected agent actions: run preflight first, detect existing Datadog mapping, skip create when present, still run verification, and return an idempotent outcome summary.

tip Ask the agent to assess an existing Sentry, Datadog or PagerDuty configuration and surface gaps or areas of concern.

Pattern 7: Workflow Output Hardening

Use this pattern before sharing manifests across teams or repositories.

Prompt:
Harden workflow outputs so secrets are never exposed. Review and patch workflow manifests accordingly.

expected Expected agent actions: inspect manifests, remove steps/flags that expose secret-bearing fields, sanitize examples/placeholders, save, and revalidate workflows.

Pattern 8: Export Workflows with Run Order

Use this pattern to produce operational documentation such as a README.md.

Prompt:
Export all integration workflows to docs/workflows and include a run-order README with important notes.

expected Expected agent actions: export runtime workflows into the repository, verify files exist, add execution order and safety notes, and report exact file paths.

Pattern 9: Read-Only Executive Summary

Use this pattern when leadership status is needed without changes to configuration or resources.

Prompt:
Run only read-only workflows to extract data and provide an executive summary for leadership.

expected Expected agent actions: execute only preflight/audit workflows and provide status, key risks, and next actions with no writes.

tip Some agents support scheduled cron jobs for repeated report generation. Oatty workflows allow agents to derive data deterministically in scheduled jobs.

Pattern 10: Controlled End-to-End Test

Use this pattern for controlled test windows with explicit approval checkpoints.

Prompt:
Perform a controlled end-to-end test with explicit approval gates: configure, validate draft monitor, optional publish, optional rollback.

expected Expected agent actions: stage workflow runs in sequence, pause before paging-capable steps, execute only approved gates, and return to a safe state (draft/delete) when requested.

tip For reviewing any generated workflow in the TUI, use `/docs/learn/workflows-basics`.

Verify Accounts and Access (Manual Check)

Before prompting an agent, confirm the accounts and permissions exist for Sentry, Datadog, and PagerDuty.

Your agent can check the existence of headers attached to a catalog but Oatty never provides values. Values mut be input by the user before commands can be run. The rest of the playbook assumes you can authenticate to each API with the needed scopes and that required auth headers are already set.

expected You have valid credentials/tokens for all three systems and you know which org/account you are targeting.

tip Start in a sandbox/non-production environment when possible, then repeat in production after the workflow is reviewed.

tip Useful links: MCP setup `/docs/learn/mcp-http-server`, workflow review `/docs/learn/workflows-basics`, and execution guardrails `/docs/learn/how-oatty-executes-safely`.

Connect Oatty to Your Agent (MCP)

Expose Oatty to your agent through MCP so the agent can discover Oatty tools and request preview/validation/execution flows.

With an active MCP connection, the TUI shows interactions, workflow state changes, and tool calls in real time so you can observe execution as it happens.

Keep the trust model: the agent can propose and create, but execution remains explicit and observable.

tip Follow the MCP server setup page: `/docs/learn/mcp-http-server`.

tip Review the trust model for assisted execution: `/docs/learn/how-oatty-executes-safely`.

tip Review proposed and running workflows in the Workflows view; details are covered in `/docs/learn/workflows-basics`.

advanced Asking your agent to execute read-only commands for discovery is a common use case and can lead to better overall accuracy and guidance.

Prompt the Agent to Import APIs and Verify Headers

Use a short prompt to have the agent import OpenAPI schemas for Sentry, Datadog, and PagerDuty into Oatty as catalogs.

Ask it to verify the necessary headers (for example, `Authorization`) are present so authenticated commands are ready without exposing secrets in chat or workflows.

Prompt:
Import APIs for Sentry, Datadog, and PagerDuty into Oatty using their OpenAPI schemas (URLs or local paths). Verify required auth headers (e.g., Authorization) are configured for each catalog, then summarize what was imported and what is ready. Use https://raw.githubusercontent.com/DataDog/datadog-api-client-go/master/.generator/schemas/v2/openapi.yaml for DataDog.

expected Three catalogs are imported and you can search commands for each vendor immediately.

recovery If an OpenAPI schema import fails, have the agent try a local file, confirm OpenAPI v3, or import just one vendor at a time to narrow the error.

Verify Headers in the Oatty TUI (Catalog Headers)

In the Library view, set each imported catalog's auth header values.

Keep secrets out of workflow YAML and out of agent prompts while still enabling authenticated discovery and execution.

tip See the headers editor flow: `/docs/learn/library-and-catalogs#headers-management`.

expected Authenticated read-only calls succeed (list orgs/projects/services) before you attempt any mutating setup steps.

tip Use minimum scopes first. Expand permissions only when you hit a specific blocked step.

Why This Is Written as a Playbook

Integrations tend to fail in the “last mile”: permissions, identifier mismatches, missing providers, and unsafe test notifications.

A playbook reduces iteration time by making the sequence explicit and by separating safe validation from mutating steps.

This same structure scales to more complex configuration work (for example, error deduping, SLO thresholds, and escalation routing), where manual YAML/JSON editing and repeated trial runs are otherwise the default.

expected You get a repeatable baseline with clear verification points and rollbacks, which reduces alert fatigue and missed incidents caused by subtle misconfiguration.

tip When you expand this beyond integrations, keep the same pattern: preflight -> validate -> draft/safe create -> controlled enablement -> verify -> rollback.

tip Agent prompt: Ask the agent to keep mutating steps behind explicit validation/preview, and to start with draft or non-notifying configurations.

Current Integration Style

Sentry <-> PagerDuty: native Sentry PagerDuty integration actions.

Datadog <-> PagerDuty: service-key mapping via Datadog PagerDuty integration.

Sentry <-> Datadog: no native provider was available in the verified org at the time of testing; treat this as a provider availability check.

expected Sentry provider availability can differ by org. Always check before assuming a native Sentry → Datadog install flow exists.

Preflight

Confirm Oatty provider auth is valid for `sentry`, `datadog`, and `pagerduty` catalogs/plugins.

Confirm target identifiers (at minimum): Sentry org slug and PagerDuty service name.

Never store PagerDuty integration keys in git. Treat them as secrets and store them using your secrets backend.

tip For a new environment, start by running read-only commands to validate auth/scopes before drafting any workflow that creates or mutates resources.

tip Minimal prompt: Prompt: "List the identifiers we need (org slug, service ID, integration ID) and propose read-only commands to fetch them in each system."

Confirm Sentry Integration Provider Availability

Confirm that Sentry has the expected integration providers available in the target org.

You want to see PagerDuty present. Datadog may or may not exist.

# List integration providers for an org
sentry organizations:config:integrations:list <ORG_SLUG>

# Optional targeted check
sentry organizations:config:integrations:list <ORG_SLUG> --providerKey datadog

expected `pagerduty` provider exists. If `datadog` provider is missing, treat native Sentry → Datadog install as unavailable.

recovery If a provider is missing, use alternate forwarding patterns instead of trying to force a native install flow.

tip Minimal prompt: Prompt: "Check which integration providers exist for this Sentry org and summarize what is available for PagerDuty and Datadog."

Confirm PagerDuty Service + Events API v2 Integration

Identify the target PagerDuty service.

Fetch integrations for the service and locate the Events API v2 integration (integration key is a secret).

# List services
pagerduty services:list

# Fetch service info including integrations
pagerduty services:info <SERVICE_ID> --include[]=integrations

# Fetch integration info (use integration ID from previous output)
pagerduty services:integrations:info <SERVICE_ID> <INTEGRATION_ID>

expected You can capture `service_name` and the Events API v2 `integration_key` (keep secret).

tip Prefer unambiguous service names to reduce routing mistakes and future maintenance risk.

tip Minimal prompt: Prompt: "Find the PagerDuty service we should route to, list its integrations, and tell me which one is Events API v2."

Configure Datadog -> PagerDuty Mapping

Create the service-key mapping in Datadog using the PagerDuty service name and Events API v2 integration key.

Then verify the mapping exists.

# Create mapping
datadog api:integration:pagerduty:configuration:services:create \
  --service_name "<PAGERDUTY_SERVICE_NAME>" \
  --service_key "<PAGERDUTY_EVENTS_API_V2_INTEGRATION_KEY>"

# Verify mapping
datadog api:integration:pagerduty:configuration:services:info "<PAGERDUTY_SERVICE_NAME>"

expected The mapping exists and the response contains the target `service_name`.

recovery If creation fails, re-check token scopes/permissions and confirm the integration key is correct for the target service.

tip Minimal prompt: Prompt: "Create (or update) the Datadog PagerDuty service mapping for <service_name>. Then verify it exists."

Validate Datadog Notification Handle (No Paging)

Validate a monitor payload without creating a monitor or paging.

This is a safe check for message format and handle resolution.

datadog api:monitor:validate:create \
  --type "query alert" \
  --query "avg(last_5m):avg:system.load.1{*} > 100000" \
  --name "integration-validation-pd-handle" \
  --message "Datadog->PagerDuty validation @pagerduty-<SERVICE-NAME-HANDLE>" \
  --options '{"notify_no_data":false,"thresholds":{"critical":100000}}'

tip Recommended handle format example: `@pagerduty-Default-Service`.

expected Payload validation succeeds without creating a monitor.

tip Minimal prompt: Prompt: "Validate a Datadog monitor payload that would route to PagerDuty, without creating a monitor or notifying."

Create a Draft Datadog Validation Monitor

Create a monitor in draft mode so it does not notify.

This provides a persisted artifact you can inspect and later enable under controlled incident testing.

datadog api:monitor:create \
  --name "integration-validation datadog-to-pagerduty" \
  --type "query alert" \
  --query "avg(last_5m):avg:system.load.1{*} > 100000" \
  --message "Datadog to PagerDuty validation @pagerduty-Default-Service" \
  --tags '["integration:datadog-pagerduty","env:production","managed-by:oatty"]' \
  --priority 3 \
  --draft_status draft \
  --options '{"notify_no_data":false,"include_tags":true,"thresholds":{"critical":100000}}'

# Verify
datadog api:monitor:info <MONITOR_ID>

expected `draft_status` is `draft`, and the message contains the PagerDuty handle.

tip Keep validation monitors in draft unless you are running a controlled incident test.

tip Minimal prompt: Prompt: "Create a Datadog validation monitor in draft mode with the PagerDuty handle, then fetch it and confirm draft_status."

Validate Sentry -> PagerDuty Actions

Verify at least one Sentry alert rule or workflow includes a PagerDuty action with a non-null integration identifier.

This confirms Sentry is wired to incident response in a concrete, inspectable way.

# Alert rules
sentry organizations:alert-rules:list <ORG_SLUG>

# Workflows (optional)
sentry organizations:workflows:list <ORG_SLUG> --project [<PROJECT_ID>]

expected You see action type `pagerduty` and a non-null integration identifier.

recovery If no PagerDuty actions exist, create or edit a rule/workflow and add a PagerDuty action via the integration.

tip Minimal prompt: Prompt: "List Sentry alert rules/workflows and confirm at least one routes to PagerDuty. If none do, propose the smallest safe change to add one."

Rollback

Datadog PagerDuty mapping rollback:

Datadog validation monitor rollback:

Sentry PagerDuty rollback:

# Datadog PagerDuty mapping rollback
datadog api:integration:pagerduty:configuration:services:delete "<PAGERDUTY_SERVICE_NAME>"

# Datadog validation monitor rollback
datadog api:monitor:delete <MONITOR_ID>

# Sentry PagerDuty rollback
# Remove PagerDuty actions from rules/workflows in Sentry, or disable impacted workflows.

tip Test rollback paths in non-production first.

Re-run Checklist

Provider auth confirmed.

PagerDuty service and integration key confirmed.

Datadog mapping created or updated.

Datadog monitor payload validates.

Draft monitor exists and is query-valid.

Sentry rules/workflows include PagerDuty actions.

Rollback commands tested in non-production first.

expected You can re-run this playbook safely after org migrations, service renames, or key rotation.