From monitoring to controlled DevOps.
Three tiers. One goal: server confidence.
Watchdog Mode
Watchdog runs configured checks and sends alerts. Supported button-tap actions follow runtime policy; this mode does not require AI.
For DevOps, SRE, and teams who want control
- Status monitoring — CPU, RAM, disk, services — always visible
- Crash alerts — Get an alert when a configured check detects a supported failure
- One-tap fixes — Approve restart or repair actions for common services from chat
- Docker management — Container lifecycle from chat
- Triggers — If X happens, do Y. You define the rules.
- Playbooks — Supported scripts create approval-required actions
- Dashboard — Web UI for multi-server overview
- Audit logs — Recorded approval decisions, supported actions, and results
Deployment Bro
Talk to your servers in plain English. Bro assembles context, diagnoses supported problems, and runs supported actions under runtime policy.
For vibe coders and builders who ship fast
- Natural language — "Why is my app slow?" gets a real answer
- Context-aware — Bro remembers your setup and history
- Smart diagnosis — 9 recipes — reads logs, finds root cause, explains simply
- Git deploys — "Deploy my changes" — done, with auto-rollback for supported deploy modes
- Investigation Mode — Explicitly authorized, bounded execute_command session for AI clients
- Anomaly dashboard — 9 detectors with auto-mute and rate limiting
- 40 MCP tools — Full access from Claude Code, Cursor, Codex
- BYOK — Use your own OpenAI/Anthropic API key
- Everything in Watchdog — All alerting and approved action features included
LAYER 4: Investigation Mode (for AI clients)
Explicitly authorized, server-scoped execute_command bypass for an AI-assisted incident session.
Problem: Per-action 2FA breaks AI flow. A debug session is 5–10 exec actions, each requiring a push notification + approve. AI assistants (Claude Code, Cursor, Codex) lose context between approvals; operators get fatigued.
Solution: Explicitly authorize an Investigation session, then mttrly_execute_command can run within that session's server, inactivity, hard-cap, and action limits. The bypass closes automatically when a bound is reached or the user revokes it.
- ✓Server-scoped — bypass on one server doesn't apply to another
- ✓Atomic action counter — racing callers can't exceed max_actions
- ✓Bypass applies only to mttrly_execute_command. mttrly_execute_script, file writes, repair, and agent updates remain per-action approval-required
- ✓Tunable per acquisition — inactivity 1–120 min, max actions 1–100
- ✓Hard cap is non-tunable (2h) — prevents accidentally opening bypass for 24h
Designed specifically for the Claude Code / Cursor / Codex workflow. Available on Deployment Bro and above.
Anomaly Management
Proactive monitoring with auto-mute, rate limiting, and a dashboard you actually use.
Detectors that ship today
systemd_pm2_mismatch — Service running under PM2 but no matching systemd unit (or vice versa)port_service_mismatch — Listening port but no matching service definitionkernel_error — dmesg errors — OOM kills, hardware faults, segfaultsstale_backups — Backup jobs not running on schedulesystemd_unit_drift — Unit file changed since last known-good stateincident_spike — Sudden cluster of incidents on a serverdeploy_failure_cluster — Multiple deploys failing in a windowinvestigation_churn — Same problem investigated repeatedly without resolutionagent_update_stale — Agent version is behindHow it works in practice
- ✓FP-budget auto-mute — repeated false positives on a rule auto-mute it
- ✓Notification rate limiter — no 3 AM page-storms
- ✓Acknowledge proactive events — mark as accepted or false positive
- ✓Anomalies dashboard — review, ack, and mute from one screen
- ✓Morning brief — proactive findings + recent knowledge in one digest
Quick comparison
| Capability | Watchdog | Deployment Bro | Deployment Crew |
|---|---|---|---|
| How you interact | Buttons & /commands | Plain English | Plain English |
| Servers | 1 | 3 (+$15/extra) | 9 (+$15/extra) |
| Learning curve | Zero | Zero | Zero |
| Crash alerts + approved fixes | ✓ | ✓ | ✓ |
| Alerts | ✓ | ✓ | ✓ |
| Dashboard | — | ✓ | ✓ |
| Natural language | — | ✓ | ✓ |
| Smart diagnosis (9 recipes) | — | ✓ | ✓ |
| Bounded execute_command Investigation | — | ✓ | ✓ |
| Anomaly dashboard | — | ✓ | ✓ |
| Proactive monitoring | — | ✓ | ✓ |
| Approved fixes | Common services | Simple issues | Simple issues |
| Git deploys | — | ✓ | ✓ |
| Deploy pipeline | — | ✓ | ✓ + webhooks (soon) |
| Team access | — | — | Coming Soon |
| Provisioning | — | ✓ | ✓ |
| MCP tools | Starter access | 40 | 40 |
| Support | Community | Priority |
Feature Deep Dive
Further Reading
Site Reliability Engineering: How Google Runs Production Systems ↗
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy · Book (Free Online)
The foundational SRE text defining MTTR, monitoring, alerting, and incident response practices used by Google and adopted industry-wide.
Accelerate: The Science of Lean Software and DevOps
Nicole Forsgren, Jez Humble, Gene Kim · Book
Research-backed evidence that MTTR is one of the four key metrics predicting software delivery performance and organizational outcomes.
Observability Engineering: Achieving Production Excellence
Charity Majors, Liz Fong-Jones, George Miranda · Book
Modern observability practices that reduce MTTR by improving detection and diagnosis — moving beyond traditional monitoring.
Connect one server and test the real workflow.
Signup starts with email. Inside-server diagnostics require the outbound agent; approval-required actions normally wait for you, with bounded Investigation and configured preauthorization as audited exceptions.