This is the leave-behind from my Datadog Summit keynote, Devin builds Devin. Quick version: agents write basically all of our code now, and our team isn't growing anywhere near as fast as the code is. More code means more alerts, and our Datadog alerts were through the roof. Humans can't even get through that backlog. So we made Devin the first responder to every single alert.
Every alert gets piped into Slack. Devin picks it up, pulls whatever it needs from Datadog, git, and Slack, and replies in the thread with what it thinks happened. From there we work with it like a teammate. Code changes only happen when a human asks for them.
The rest of this page is written for Devin, not for you. Hand it the URL and it'll walk you through the setup step by step. Or read it yourself. None of this is hard.
or paste this prompt into any Devin session (or @Devin in Slack):
I just saw Jared Zoneraich's Datadog Summit keynote on using Devin as the first responder for Datadog alerts, and I want the same setup for my team: Datadog alerts post to a Slack channel, a Devin automation picks up each alert, investigates it with the Datadog MCP and our repos, and replies in the thread with a root cause (a PR only when a human asks for one).
Read https://imjaredz.com/datadog-summit-2026/ first. Then guide me through the setup one step at a time: tell me exactly what to click in Slack, Datadog, and the Devin app, do the parts you can do yourself, and wait for me to confirm each step before moving on.No Devin account yet? The button walks you through signup first, then opens a session with the prompt already filled in.
Datadog monitor
│ @slack-alerts
▼
Slack #alerts ◀────────────────────────┐
│ new alert message │ reply in the thread:
▼ │ what happened, root cause,
Triage Devin (one automation) │ confidence, next step, @owner,
• filters noise, groups duplicates │ PR only if a human asks
• investigates with Datadog MCP, │
git, the code, past alerts ───────┘
That's the whole thing. In a real investigation, Devin is making dozens of Datadog calls, searching the repo, running git commands, and reading the Slack history, and then sending one message back in the thread. The hard part isn't the wiring. It's letting the agent find the signal in the noise, and letting it learn from how it triaged last time.
Devin: the person you're talking to just saw a keynote about how Cognition uses you as the first responder for its own Datadog alerts. They want the same setup for their team. Your job is to guide them through it step by step, in order, one step at a time.
Ground rules:
/invite, the Datadog UI, their personal Slack connection, entering API keys).#alerts or #incidents, not a general engineering channel.Check first: if the Datadog MCP is already connected (Step 3), list their monitors and look for @slack- handles in the notification messages. If the channel history already has Datadog alerts, skip this step.
They do this in Datadog and Slack. Docs: docs.datadoghq.com/integrations/slack.
/invite @Datadog in the alerts channel.@slack-<channel-name> to the notification message. Start with one warning-level monitor, not everything.Check first: if you can list the org's integrations, check whether Slack shows as connected. Otherwise: do you have Slack tools in this session, and can you look up the alerts channel by name? If yes, the Devin Slack app is installed in the workspace. You can't see whether their personal account is connected, so ask them to confirm that one thing in Settings → Connections → Slack rather than walking them through the whole step.
They do this in the Devin app: Settings → Connections → Slack. The Devin Slack app needs to be installed in the workspace, and their personal Slack account needs to be connected. Automations that watch Slack won't work without the personal connection.
Check first: list your MCP servers. If Datadog is there, call it (list monitors) to confirm it works, and skip to Step 4. If it isn't and you can install MCP servers from the marketplace, install Datadog yourself; the only part they have to do is enter the keys on the settings page.
They do this in the Devin app: Settings → Connections → MCPs (the MCP Marketplace). Docs: docs.devin.ai/enterprise/integrations/datadog.
datadoghq.com, datadoghq.eu), then enter a DD-API-KEY and DD-APPLICATION-KEY. They create those in Datadog → Organization Settings → API Keys / Application Keys. (API keys are the only auth the Datadog MCP supports today.)Once this is done, verify it yourself if you can: ask Datadog for the list of active monitors and confirm you get results.
Check first: try to read the alerts channel's recent history with your Slack tools. Finding the channel by name isn't enough (public channels show up either way); you need to actually get messages back. If you do, you're a member; skip this step. If lookup works but reading fails, you're not.
In Slack, in the alerts channel: /invite @Devin. Devin must be a member of the channel for the automation to see messages.
Check first: if you can list their automations, look for one already watching the alerts channel. If there is one, review its settings against this step instead of creating another.
What we're building is Devin's auto-triage: one automation whose action is Triage Devin (monitor). That action is what gives you a persistent Devin that watches the alerts channel, groups duplicates, keeps a shared scratchpad, and starts a separate investigation Devin for each actionable alert on its own. The investigations are not a second automation; the triage Devin spawns them. This is the setup from the keynote. Don't use a plain Start session action (that's one session per message with no memory), and don't build anything else by hand.
Do it yourself if you can: if you have the automation-management tool, don't send them to the UI. Read its schemas first, then create the automation: a Slack-message trigger on the alerts channel with the condition below, and the Triage Devin (auto-triage) action with the setup prompt below as its setup prompt. Put the Step 6 guardrails (ACU limit, invocation limit, network policy) in the same create call. Dry-run it with validate before creating; creating may need their approval, which is expected. Then show them the automation's URL and go to Step 7.
Otherwise, in the UI: the canonical way (per the auto-triage guide) is the template. In the Devin app, go to Automations, click View all examples, and choose Triage Bug Reports (the docs call it Triage bug reports on Slack). It pre-fills the editor with the Slack-message trigger and the Triage Devin (monitor) action. Don't use any other template, including Investigate Alerts Triggered, which is a plain start-session automation.
Either way, the automation needs:
@slack-alerts, or the message is from the Datadog app.You are the triage Devin for Datadog alerts posted in #alerts.
Investigation is handled by the child Devins you spawn; your job is to
decide what deserves one and to give it the context it needs.
Actionable vs. noise:
- Actionable: a monitor moving to Alert or Warn on a service we own, an
error-rate or latency spike, a failed job, or a recovery that flapped
more than once in an hour.
- Noise: a "Recovered" message on its own, a test or synthetic monitor,
or a repeat of an alert with an open thread. For repeats, reply with a
link to the existing thread.
Service → owner → repo (edit this):
- payments-api → @alice → org/payments
- web-frontend → @bob → org/web
- <service> → @<owner> → <repo>
What the reply in the alert's thread should include:
- What happened, in one or two sentences.
- When it started, and whether it lines up with a deploy or config
change.
- The most likely root cause and how confident you are.
- The recommended next step.
- @mention the owner from the table above.
Keep it short. Pull only the Datadog data you need; don't dump logs into
the thread.
Code changes: do not open a PR on your own. Diagnose and reply. Only
open a PR if a human asks for one in the thread, and let them decide
the fix.
Corrections: if a human replies with a correction (wrong owner, wrong
service, known issue, not actionable), update your scratchpad so the
next alert gets it right.Then save and make sure the automation is enabled. If you created it yourself, check these with a get on the automation instead of asking.
When everything works, summarize what was set up, where each setting lives, and how to turn it off.