No vague benefits — just the actual mechanics. Pulled straight from the codebase that's running in production.
Uptime, SSL, and homepage health are stitched together so you see the cause, not just the symptom.
HTTP/HTTPS at plan-driven intervals. Per-site timeout, expected status code, follow-redirect toggle, SSL verification toggle. Response time recorded to the millisecond. Body size capped at 1 MB so a misconfigured giant response can't crash a check.
Issuer, subject CN, SAN list, valid-from/valid-to, expiry days, hostname match (with wildcard), self-signed and not-yet-valid detection. Tiered alerts at 30, 14, 7, and 3 days remaining. Each tier fires once — no daily nag emails.
Title, meta description, h1, canonical, noindex directive, robots.txt, sitemap.xml — checked daily. Plus integrity classification: PHP fatals, framework crash pages, and database errors are recognised as backend incidents, not SEO issues.
When a check is blocked by Cloudflare's bot-protection challenge, Monitrova surfaces "blocked by bot protection" explicitly instead of telling you your healthy site is down. No more false outages from your own WAF.
If the last 5 successful checks all exceeded 5 seconds, the site is flagged for the operator without firing a down alert. Catches creeping degradation before customers notice.
Drop any HTTPS webhook URL into a site's settings. Every alert and recovery fires a JSON POST: site, alert type, severity, subject, timestamp, incident link. Slack-compatible text field at the top level for instant Slack integration.
This is what most monitors don't have. Every alert decision passes through a service that knows the difference between a blip and a real problem.
Non-critical issues — missing canonical, brief 503, transient SSL handshake glitch — start a suspected incident. No email yet. The next scan either confirms (alert fires) or clears it silently (no email at all). One-off blips never reach your inbox.
Critical issues skip confirmation — site down, SSL invalid, homepage noindex, backend error. Email immediately.
When the same (site, problem) opens and recovers three or more times in 24 hours, individual alerts stop and one daily digest takes over. Per-site bundle: failure counts, recovery counts, first/last seen times, related incident IDs, likely-cause checklists.
Backend errors listed first; SEO failures show as (likely downstream of [primary]).
Even when an incident keeps misbehaving, alert frequency doubles each repeat (capped at 24h). A long outage doesn't translate to one email every 60 seconds.
If the original alert was held back — for any reason: cooldown, suspected, flapping summary, quiet hours — the corresponding recovery is suppressed too. You never get "great news, your site is back up!" for an outage you weren't told about.
Per-account, IANA-timezone aware. Non-critical alerts hold back inside the window — site-down, SSL-invalid, and homepage-noindex still go through. Defaults differ by account type: solo operators get send-recoveries on; agencies get them off.
Strict, standard, or quiet — set per site. Multiplies the cooldown window. Lets agency users tune noisy clients without affecting the rest of their portfolio.
Every check result runs through a precedence classifier with weighted categories. Highest-priority issue wins; related downstream issues are explicitly listed as suppressed.
| transport | 100 | DNS · connection refused · timeout |
| cf_challenge | 95 | Cloudflare bot-challenge response |
| ssl | 90 | Invalid · expired · hostname mismatch |
| http_availability | 80 | Unexpected status (got 500, expected 200) |
| backend | 70 | Database error · PHP fatal · framework crash |
| rendering | 60 | Blank or partial output |
| seo | 30 | Title · meta · h1 · canonical · robots · sitemap |
| healthy | 0 | All checks passed |
That's why a homepage rendering "Error establishing a database connection" triggers a backend incident — not three "missing meta tag" warnings.
Sent, suppressed, deferred, or summarised — with the reason. Visible in the UI alongside the email subject line, recipient, and provider message ID.
Email reached the SMTP server (or Mailgun API). Mailgun message ID and HTTP status captured.
Decision service ruled it out. Reason: cooldown, awaiting confirmation, recovery_no_original, or preference_disabled.
First failed scan started a suspected incident. Waiting for the second scan to confirm or clear.
Site is flapping. Folded into the daily digest instead of firing individually.
Generated 1st of each month. Per site: uptime %, total checks, average + 95th-percentile response time, incident timeline, SSL snapshot, homepage status. Rendered from stored history — no live checks at report time.
Fires only when a site is actively flapping; otherwise silent. Bundles failure/recovery counts per type, first/last seen times, and a likely-cause checklist. Backend errors first; SEO failures shown as downstream symptoms.
The free plan covers one site forever. Add a URL and the first uptime check fires within a few minutes.