Monitors
Monitors are the core of Warden. Give a monitor a name and a URL, and Warden starts checking it immediately — your first result appears within seconds.
Creating a Monitor
Section titled “Creating a Monitor”- From the dashboard, click Add Monitor
- Fill in:
- Name — a unique display name
- URL — the HTTP or HTTPS endpoint to monitor
- Group — which group this monitor belongs to (use Default if you don’t need groups)
- Interval — how often to check (default: every 60 seconds)
- Click Create
That’s it. Warden runs the first check immediately and shows the result on the dashboard.
Monitor States
Section titled “Monitor States”| State | Meaning |
|---|---|
| Up | Responding successfully within latency threshold |
| Degraded | Responding but slower than the latency threshold |
| Down | Failing checks (confirmed after consecutive failures) |
| Paused | Monitoring stopped — no checks running |
| Maintenance | Group is in a maintenance window — checks run but notifications are suppressed |
Pausing and Resuming
Section titled “Pausing and Resuming”Pause a monitor to temporarily stop checks without deleting it. Resume to start checking again immediately. Historical data is preserved.
Advanced Settings
Section titled “Advanced Settings”Most monitors work great with the defaults. These settings are available when you need more control.
Per-Monitor Overrides
Section titled “Per-Monitor Overrides”Override the global defaults from Settings for individual monitors:
| Field | Range | Global Default | Description |
|---|---|---|---|
| Confirmation Threshold | 1–100 | 3 | Failed checks before confirming down |
| Notification Cooldown | 0–1440 min | 30 min | Pause between repeat notifications |
| Latency Threshold | 1+ ms | 1000 ms | Latency above this = degraded |
Request Configuration
Section titled “Request Configuration”Customize the HTTP request Warden sends:
| Field | Default | Description |
|---|---|---|
| Method | GET | HTTP method (GET, HEAD, POST, PUT, DELETE) |
| Headers | — | Custom request headers (max 50) |
| Body | — | Request body for POST/PUT (max 10 KB) |
| Timeout | 5s | Request timeout (1–120 seconds) |
| Follow Redirects | Yes | Whether to follow HTTP redirects |
| Accepted Status Codes | < 400 | Custom success criteria |
| Retry Count | 0 | Retries on failure (0–5, 1s delay between) |
Accepted Status Codes
Section titled “Accepted Status Codes”By default, any status code below 400 is considered successful. Customize with individual codes, ranges, or both:
200,201,301200-299200-299,301,302
Uptime & Latency
Section titled “Uptime & Latency”Each monitor tracks:
- Uptime over 24 hours, 7 days, and 30 days (percentage of successful checks)
- Latency displayed in 4 time ranges: 1 hour, 24 hours, 7 days, and 30 days
Alerting Behavior
Section titled “Alerting Behavior”Warden doesn’t alert on the first failure — it waits for confirmation to avoid false alarms.
Confirmation threshold: By default, 3 consecutive failures are required before a monitor is confirmed down and a notification is sent. Change this globally in Settings or per monitor.
Notification cooldown: After sending an alert, Warden waits 30 minutes before sending another for the same event type. This prevents alert fatigue during extended outages.
Flap detection: If a monitor keeps flipping between up and down, Warden recognizes the instability and sends a single “flapping” alert instead of many individual alerts. Once the monitor stabilizes, you get a “stabilized” notification.
Recovery confirmation: Warden can require consecutive successful checks before confirming recovery, preventing false recovery alerts. Default is 1 check, configurable up to 20 in Settings.
SSL Certificate Monitoring
Section titled “SSL Certificate Monitoring”For HTTPS monitors, Warden automatically tracks SSL certificate expiry and alerts you at 30, 14, 7, and 1 day before expiry. SSL alerts are sent once per threshold during a mid-day window in your timezone.
Event Types
Section titled “Event Types”| Event | Trigger |
|---|---|
| down | Monitor confirmed down |
| up | Monitor recovered |
| degraded | Latency exceeded threshold |
| recovered | Latency returned to normal |
| flapping | Rapid state changes detected |
| stabilized | Flapping stopped |
| ssl_expiring | SSL certificate approaching expiry |
Each event type can be toggled on/off and optionally routed to a daily digest in Notifications.
Data Retention
Section titled “Data Retention”Check history is automatically cleaned up based on the retention period in Settings (default: 365 days, range 1–3650). Monitor metadata, events, and outage records are kept indefinitely.
Deleting a Monitor
Section titled “Deleting a Monitor”Deleting a monitor permanently removes it along with all check history, events, and outage records. This cannot be undone.