Fail2ban: from intentional stop to verified recovery
In a controlled founder test, mttrly detected an intentional Fail2ban stop, prepared a bounded remediation, and waited for separate human approval. The alert appeared after 6m14s; alert-to-resolution took 36s, including about 3s from approval to verified recovery, for an end-to-end cycle of about 6m50s.
The test ran on the founder's own server in May 2026. Fail2ban was stopped intentionally. This is product evidence, not a customer incident or testimonial.
Measured result
The clock includes the detection interval and the time spent waiting for a human decision. Approval was part of the workflow, not edited out of the result.
6m14s
In this controlled founder test, the alert appeared 6m14s after Fail2ban was stopped intentionally.
36s
In this controlled founder test, 36 seconds passed from the alert to verified resolution.
~3s
In this controlled founder test, verified resolution followed human approval in about 3 seconds.
~6m50s
In this controlled founder test, the full intentional stop-to-resolution cycle took about 6m50s.
Recorded control path
Intentional stop
Fail2ban was stopped deliberately on the founder-operated server to start a controlled end-to-end recovery test.
Alert detected
In this controlled founder test, mttrly created the service-down alert 6m14s after the intentional stop.
Bounded action prepared
mttrly prepared the remediation as a pending action. It did not silently execute a free-form fix.
Human approval
A person reviewed and approved the pending action separately. The assistant did not approve its own request.
Recovery verified
In this controlled founder test, Fail2ban reached resolved about 3 seconds after approval and 36 seconds after the alert; the full cycle took about 6m50s.
What this proves
- +A deliberate service stop moved through detection and a pending remediation.
- +The state-changing step waited for separate human approval before execution and verified resolution.
- +The incident history starts with detection and ends with verified resolution. It also records the pending action. The human decision and execution remain visible between those points.
- +The approval gate remained part of the measured recovery path instead of being removed to make the timing look faster.
What this does not prove
- −This was not an unplanned customer outage or independent customer success story.
- −mttrly did not fix the service without a human; the state-changing action waited for separate approval.
- −One controlled service test does not establish a universal recovery time for every server, incident, policy, or network condition.
- −mttrly does not replace SSH or a provider console as the bootstrap and break-glass path.
Evidence and privacy boundary
- Source record
- C02: Redacted internal Fail2ban recovery evidence record
- Environment
- Founder-operated server / intentional service stop
The public page is derived from a redacted internal evidence record. Hostnames, IP addresses, identifiers, tokens, and raw command output are intentionally excluded.
The public claim is intentionally narrower than the internal record. For product behavior, see how mttrly separates diagnostics, pending remediation, approval, execution, and audit history.
Supporting mobile path
Review and approve from Telegram
See the optional mobile interface for alerts and human decisions. The agent and policy layer still perform the server work.
Put a human approval gate in the recovery path
Start with one Linux server and install the outbound agent. Use scoped diagnostics first; state-changing work can follow the approval path. The free Watchdog plan is enough to connect the first server.
Connect one serverStart free. If you upgrade to Deployment Bro, BETA75 gives 75% off the first three months.