← mttrly.com/Technical details

How mttrly works

Technical architecture and AI pipeline.

Architecture

Central service in Node.js/TypeScript with WebSocket connections. Lightweight agent process on customer servers executes prepared playbooks and scoped local commands, then streams structured results back. PostgreSQL for audit logs and incident history. Hosted at app.mttrly.com.

AI Pipeline

The hosted configuration separates lighter intent and formatting work from heavier diagnosis and remediation planning. Current defaults use Claude Haiku and Claude Sonnet, while provider and model choices remain configuration rather than a fixed product promise.

The split reduces cost and latency while maintaining quality on reasoning-intensive tasks.

Claude Haiku — Fast triage
  • → Incident classification
  • → Intent parsing from chat, dashboard, or MCP context
  • → Message formatting
  • → Lightweight requests
Claude Sonnet — Deep reasoning
  • → Multi-step incident diagnosis
  • → Relevant log interpretation
  • → Remediation planning
  • → Evidence-backed explanation

Safety Architecture

Every design decision assumes the AI can be wrong.

Command allowlists

Scoped diagnostics and prepared playbooks are the normal path. One-off command execution is policy-gated and audited.

Human approval flows

Risky changes normally create a pending action for a human to approve. A separately authorized Investigation session can allow a bounded set of command actions within server, time, and action-count limits.

Reviewable action history

The audit trail records operational requests, approval decisions, selected actions, and execution results. It does not promise access to a model's hidden chain of thought.

Escalation on uncertainty

Unsupported requests and uncertain diagnoses remain visible to the operator instead of becoming an unrestricted shell action.

Runtime policy, not prompt promises

The current registry separates 36 read-only playbooks from 46 approval-required playbooks. Enforcement follows that runtime classification.

Current generated registry: 82 playbooks · 36 read-only · 46 approval-required.

Playbooks

80+ built-in playbooks, currently 82 in the generated product reference:

healthcheckservice restartrollbacklog taildisk checkmemory checknginx reloadcert checkdisk cleanupport checkcontainer statusdmesg checkload checkserver discoveryand more (80+ total)

Create an account with email, then install the required outbound agent on one server.