Investigate and act after Datadog alerts
Keep Datadog for observability. Add mttrly when the next step is server investigation, approval-gated remediation, verification, and audit history.
Direct answer
Datadog tells you what is wrong; mttrly helps investigate and act after the alert. Datadog remains the observability, APM, metrics, logs, traces, dashboards, and alerting layer. mttrly is the post-alert incident response action layer for scoped server inspection, diagnostics, playbook selection, explicit approval for risky actions, verification, and audit history.
For the broader model, see the mttrly incident response action layer.
What Datadog is good at
Datadog belongs at the observability center of the stack. It helps teams see application behavior, infrastructure signals, logs, traces, dashboards, monitors, and alert history before responders choose an action path.
APM context that helps teams understand service latency, dependencies, error rates, and user-impacting behavior.
Metrics and infrastructure telemetry for CPU, memory, disk, saturation, capacity, and host-level signals.
Logs and traces that help responders correlate application behavior with infrastructure symptoms.
Dashboards, alerting, monitors, and historical context that show what changed and when the incident started.
What still happens after an alert
A Datadog alert is the starting signal. The response still needs live server context, a bounded remediation choice, explicit approval for risky work, and proof of what happened.
Inspect server reality
The responder still needs current health, active alerts, runtime facts, and service state before deciding what to do.
Read relevant logs
Logs help separate a capacity problem from a broken deploy, dependency failure, noisy process, or misconfigured service.
Run diagnostics
Focused diagnostics turn the alert signal into a safer next step instead of guessing from a metric alone.
Choose remediation
A prepared playbook or scoped action is safer than a broad terminal session when the issue is known.
Wait for approval
State-changing work should create a pending action. A human approves or rejects it before execution.
Verify and audit
After the approved action runs, the team needs a result check and a reviewable audit trail.
Datadog vs mttrly
| Row | Datadog | mttrly |
|---|---|---|
| Primary role | Observability, APM, metrics, logs, traces, dashboards, monitors, and alerting. | Post-alert incident response action layer for investigation, approval-gated remediation, verification, and audit. |
| Best question | "What is unhealthy, where did it happen, and what changed over time?" | "What can we safely inspect, diagnose, or request on this server next?" |
| Data read | Telemetry, events, logs, traces, metrics, alert history, service maps, and dashboards. | Connected server status, service reality, logs, diagnostics, playbooks, pending actions, and audit history. |
| Action model | Detect, visualize, correlate, notify, and give response context. | Inspect, diagnose, choose a playbook, request an action, execute approved work, and verify results. |
| Human approval | Handled by your incident process and operational controls. | Risky state-changing actions require explicit human approval before execution. |
| Mobile path | Alert review and dashboard context through your existing response workflow. | Telegram or dashboard review for pending actions when configured. |
| Audit trail | Alert, monitor, event, dashboard, and telemetry history. | Requested actions, approval decisions, diagnostics, execution results, and follow-up context. |
Example workflow: Datadog alert -> mttrly action request
This keeps Datadog as the alerting and observability layer, and mttrly as the responder-controlled action layer after the alert.
Datadog alert fires
A monitor points to high error rate, disk pressure, latency, or another production symptom.
Responder opens Claude Code, Cursor, or Codex with mttrly MCP
The alert is the signal. The responder starts a controlled investigation path through mttrly MCP.
mttrly checks server status, logs, and service reality
The assistant can read health state, relevant logs, current service facts, and recent operational context.
mttrly proposes a playbook or scoped action
The AI can inspect, diagnose, choose a playbook, and request an action, but it does not approve risky work for itself.
Human approves from Telegram or dashboard
A responder reviews the pending state-changing action and explicitly approves or rejects it.
mttrly verifies and records audit
After approved execution, mttrly checks the result where possible and records the response trail.
When to use both
Datadog and mttrly fit together when alert quality is good but the response still needs faster investigation, clearer guardrails, and an auditable action path.
You already trust Datadog for observability
Keep Datadog as the source of telemetry, monitors, dashboards, and historical context.
Your team still loses time after alerts
mttrly helps move from alert context to current server facts, diagnostics, remediation options, and verification.
You want AI-assisted response with boundaries
Claude Code, Cursor, and Codex can investigate through MCP while state-changing work remains approval-gated.
You want mobile approval without handing over SSH
Telegram or dashboard approvals give responders a phone-friendly way to review pending work.
Useful next pages
- +Read the incident response action layer overview for the bigger MCP positioning.
- +Connect Claude Code, Cursor, or Codex through the mttrly MCP server.
- +Compare roles on mttrly vs monitoring tools.
- +Use the same pattern for managing a VPS without raw SSH.
- +Route pending action review through Telegram approvals when responders are away from a laptop.
- +Review server limits and response features on mttrly pricing.
- +If your observability stack is Grafana-first, see Grafana + mttrly.
When mttrly is not the right layer
mttrly should not be stretched into a Datadog replacement. Use it only when you need the controlled action layer after observability has already found a problem.
- -You need APM, distributed tracing, log analytics, metrics storage, or dashboarding as the primary product need.
- -You need a direct Datadog integration or alert-to-action pipeline in the product today.
- -You want an AI system to make production changes without explicit human approval.
- -Your servers cannot run the mttrly agent or cannot maintain outbound connectivity.
- -The incident requires deep forensics, provider rescue mode, or arbitrary interactive shell work.
FAQ
Does mttrly replace Datadog?
No. Datadog remains the observability layer for APM, metrics, logs, traces, dashboards, monitors, and alerting. mttrly complements Datadog after an alert by helping a responder investigate the affected server, request approval-gated remediation, verify the result, and keep an audit trail.
Does this page assume a direct Datadog integration?
No. This page describes a stack pattern, not a direct product integration. Datadog provides the alert and observability context. A responder can then use mttrly through MCP to inspect server reality, run diagnostics, choose a playbook, and request an approved action.
Is there an alert-to-action pipeline?
This page does not describe an alert-to-action pipeline. The safe workflow is responder-led: Datadog notifies the team, then a human opens an AI IDE or dashboard path with mttrly to investigate and request any needed action.
What can an AI assistant do with mttrly after a Datadog alert?
An AI assistant can inspect server status, read logs, review service reality, run diagnostics, list playbooks, choose a bounded remediation path, and request a pending action. Risky state-changing work requires explicit human approval before execution.
Can a human approve fixes from Telegram?
Yes. When Telegram is configured, a responder can review and approve or reject pending mttrly actions from Telegram. The dashboard can also be used for approval workflows.
Is mttrly fully autonomous?
No. mttrly is designed for human-controlled incident response. AI can help inspect, diagnose, choose a playbook, and request an action, but risky state-changing work requires explicit human approval.
When should I use only Datadog?
Use only Datadog when you need observability, APM, logs, traces, metrics, dashboards, monitors, or alert routing without a separate server action layer. mttrly is for teams that also want controlled investigation, approval-gated remediation, verification, and audit after the alert.
Add an action layer after Datadog alerts
Start with read-only investigation, then add approval-gated playbooks when your team is ready to remediate incidents from an AI IDE or phone.