Security and Design
The How it works page explains the workflow. This page explains how RecoveryPulse is designed to be safe and predictable.
Recovery is optional
Monitoring works without any recovery actions enabled.
Recovery only runs if you turn it on.
Access is least privilege
If you enable recovery, set it up like you would for any production automation.
- Use key based SSH, not passwords.
- Use a dedicated non root user.
- Limit permissions to only the commands you need.
- Restrict access with firewall rules.
You control what runs
RecoveryPulse does not run random commands.
You choose the recovery steps. Keep them small and reversible, like restarting a service or clearing cache.
Guardrails prevent restart loops
Automated recovery should not flap forever.
Recovery can be limited with retry caps and cooldown delays.
If recovery keeps failing, the correct behavior is to stop and alert.
Audit trail
Every incident and every recovery action should be visible.
RecoveryPulse records incidents and recovery executions so you can see what happened and when.
Data handling
RecoveryPulse stores only what it needs to run.
Stored
- Monitored URLs and settings
- Incident results and timestamps
- Recovery configuration you create
Not stored
- Passwords
- Application secrets
- Your site content beyond what is needed to verify health
Design principles
- Safe beats clever.
- Verification beats assumptions.
- Visibility beats mystery.
If you want help hardening your setup, use the Help link in the app.