Monitoring vs Remediation
Monitoring detects problems. mttrly acts after the alert.
Grafana, Datadog, Sentry, PagerDuty, and Prometheus help teams see metrics, traces, logs, errors, alerts, and historical context. mttrly is the incident response action layer that starts after those tools raise the signal.
Direct answer
Monitoring detects; mttrly acts after the alert
Use Grafana, Datadog, Sentry, PagerDuty, Prometheus, or your existing observability stack to detect and explain incidents. Use mttrly after the alert to inspect live server reality, run scoped diagnostics, choose prepared playbooks, apply runtime policy, record the result, and run an explicit post-action check in supported workflows.
What belongs in monitoring, and what belongs in mttrly
| Capability | Monitoring tools | mttrly |
|---|---|---|
| Primary job | Detect, visualize, correlate, and route incident signals. | Diagnose and coordinate approved response after an alert. |
| Best signals | Metrics, dashboards, traces, logs, errors, alerts, and historical context. | Server reality, health state, diagnostics, playbooks, pending approvals, recorded results, and supported verification. |
| Typical question | "What is unhealthy, when did it start, and who needs to know?" | "What can we safely inspect or remediate on this server next?" |
| Action model | Usually read, alert, route, annotate, or open an incident workflow. | Inspect, diagnose, choose a playbook, apply runtime policy, execute, and run a post-action check where supported. |
| Risk control | Handled by the team response process around the monitoring tool. | Approval-required actions normally wait for human review. A bounded mttrly_execute_command Investigation or narrow preauthorization must be authorized separately and remains audited. |
| Command execution | Not the main purpose of observability tools. | Available only when enabled and scoped. Per-command approval is normal; only a user-authorized bounded Investigation can bypass it for mttrly_execute_command. Execution remains audited. |
Post-alert workflow
Read-only checks can run immediately. In the normal interactive path, approval-required changes wait for a human decision.
- 01
Alert fires
Grafana, Datadog, Sentry, PagerDuty, or Prometheus signals a problem through the existing incident channel.
- 02
Responder investigates with mttrly
A human responder or AI assistant uses mttrly to look at the affected server after the alert, not instead of the monitoring tool.
- 03
Scoped diagnostics run first
mttrly reads current server health, service reality, alerts, logs, and targeted diagnostics before proposing a change.
- 04
Playbook or action is requested
Prepared playbooks are preferred. Scoped command execution can be enabled for narrower cases, but it is treated as a controlled action path.
- 05
Human approval gates risky remediation
Approval-required actions normally create pending approvals. A bounded mttrly_execute_command Investigation or narrow preauthorization must be authorized separately; the AI must not self-authorize either path.
- 06
Verification and audit close the loop
The action record shows its status and timing, along with output. Supported remediation plans add an explicit post-action check; monitoring remains responsible for the wider system trend.
Two different jobs
Monitoring tools detect and explain signals
- +Metrics and dashboards for service and infrastructure state
- +Traces, logs, and application errors for root-cause context
- +Alerts, routing, escalation, and historical timelines
- +Trends, baselines, regressions, and capacity context
- +Shared observability context for the incident team
They answer: "What is happening, where is it happening, and how did it change over time?"
mttrly investigates and acts after the alert
- +Server reality checks for the affected host or service
- +Post-alert diagnostics that gather current operating context
- +Prepared remediation playbooks before free-form commands
- +Approval-gated action requests for risky changes
- +Post-action checks for supported workflows and reviewable incident history
It answers: "What can we safely inspect, request, approve, and check next?"
Use monitoring for visibility. Add mttrly for the controlled action layer after the signal.
Where familiar monitoring tools fit
Grafana
Dashboards, metric exploration, and alert context
Grafana remains the place to see system behavior over time. mttrly is not a Grafana alternative; it is the action layer used after a Grafana alert or dashboard investigation points to a server that needs attention.
Prometheus
Metrics collection, alert rules, and time-series context
Prometheus is excellent for measuring resource pressure and service signals. mttrly can use the alert as the starting point for live server diagnostics and approval-gated remediation.
Datadog
APM, infrastructure telemetry, logs, monitors, and alerts
Datadog helps teams correlate infrastructure and application behavior. mttrly complements that with a controlled investigate, decide, act, and check workflow when the remediation supports verification.
Sentry
Application errors, exceptions, releases, and issue context
Sentry explains application failures and affected code paths. mttrly helps responders inspect the server, choose a bounded operational response, and audit what happened after the error signal.
PagerDuty
Alert routing, escalation, and responder coordination
PagerDuty brings the right human into the loop. mttrly gives that responder a scoped action surface with diagnostics, approvals, playbooks, and audit history.
Action layer safety model
mttrly is designed for controlled response, not unattended risky remediation.
Read first
AI can inspect server status, alerts, logs, service reality, and diagnostics before recommending action.
Playbooks preferred
Known remediation paths should use prepared playbooks instead of ad hoc shell commands.
Human approval
Approval-required actions normally wait for human review. A bounded mttrly_execute_command Investigation or narrow preauthorization must be authorized separately; AI must not self-authorize either path.
Scoped commands
Command execution, when enabled, is scoped and recorded in the audit trail. Per-command approval is normal; a user-authorized bounded Investigation can apply only to mttrly_execute_command.
Verify and audit
Every action should end with a recorded result. Supported workflows add an explicit post-action check; generic commands need a separate verifier before anyone calls the service recovered.
Next places to go
FAQ
Is mttrly a Grafana alternative?
No. Keep Grafana for dashboards and the historical monitoring context. Use mttrly after the alert for live server diagnostics, runtime-policy remediation, recorded action results, and post-action checks where the workflow supports them.
Does mttrly replace Datadog, Sentry, PagerDuty, or Prometheus?
No. Those tools detect, explain, route, and contextualize incidents. mttrly complements them as the incident response action layer after the alert.
Can AI execute commands through mttrly?
Only when command execution is enabled, scoped, and audited. Prepared playbooks are preferred. Per-command approval is normal; a user-authorized bounded Investigation can skip it only for mttrly_execute_command. The AI must not self-authorize that bypass.
What happens after a monitoring alert fires?
A responder can use mttrly to inspect live server reality, run focused diagnostics, choose a playbook or request an action, apply runtime policy, record the execution result, and run an explicit post-action check where supported.
This does not make mttrly a Grafana alternative or a replacement for Datadog and Sentry. Detection stays in observability tools. After the alert, mttrly handles live server diagnostics, runtime-policy remediation, recorded results, and post-action checks in supported workflows.
Need the technical model? Explore the incident action layer.