WebCheckHanding your monitoring to someone else?
Here's what you should know.
Whether a monitoring tool is worth trusting comes down to two things: is it reliable itself, and does it do other things with your data. This page makes both clear.
Every alert should be worth reading
A false alert is more dangerous than a missed one: after three false positives, people mute notifications. Every rule below was earned from a real incident.
Down only after consecutive failures
One timeout or a single 5xx is not an incident. By default it takes 3 consecutive failures (tunable per site, 1–10). Network flapping or a thirty-second server reboot never becomes an alert.
Multi-region second confirmation
After the monitoring machine calls a failure, another vantage point tries once more. Only multiple locations failing together counts as a site incident; only the monitoring machine failing is logged as "local line trouble" — without bothering you.
Own-incident circuit breaker
When the monitoring uplink or DNS dies, every site "fails at once". We recognize this pattern — but only when literally nothing gets through (a server carrying 76% of sites once tripped this: its incident was misread as our own failure and 244 real alerts were suppressed; no more).
One incident, two emails
One continuous incident = one record = one down notification + one recovery notification. Never repeats every minute. There's even a pre-send recheck: if the site has already recovered, queued stale alerts are cancelled — no false alarms go out.
Flapping suppression
A site that keeps failing briefly in one day (default: 4 incidents in 24 hours, each under 10 minutes) is folded into the daily digest instead of alerting every time. Thresholds are per-tenant.
Gentle on your server
Sites on the same server are capped on concurrency and minimum interval, and check times carry flapping jitter to stagger them. We once ran checks on 600 sites on one machine so fast its firewall treated us as a CC attack and blacklisted us — three rate gates went in after that.
Your data is visible only to you
Tenant isolation, verified record by record
Every account is an isolated tenant. Every query touching tenant data carries a tenant condition; automated tests visit every ID-taking route as tenant B and expect nothing but 404 — if a new route isn't covered, the test fails outright.
Password and sessions
Passwords are stored as bcrypt hashes only. Failed sign in attempts are rate-limited; reset links are single-use and time-limited. Changing your password kills all old sessions instantly. The sign in page returns the same response time for nonexistent accounts and wrong passwords — no enumeration.
How we use the content of the pages you're monitoring
Used only for the checks you configure (keywords, content watch, page error detection). Content watch snapshots are visible only to you. We do not analyze, aggregate, or sell any content from your sites.
It can't become an attack springboard
You can only use monitoring on public addresses: internal, loopback, and cloud metadata addresses are refused, and resources referenced by pages are filtered the same way. Your self-hosted nodes carry token authentication and the same protection.
What platform operators can see
Platform admins may view tenant configuration and monitoring data to provide support, but read-only — they cannot modify or delete anything as you, and every such access is audited. The platform holds no third-party secrets beyond your notification channel credentials.
System mail (verification, password resets, alerts, daily reports) goes out from report@my.webchecks.site, delivered with SSL encryption. You can also configure your own SMTP to send business alerts. Alert recipients must click the confirm link first — we never mail unconfirmed addresses, otherwise anyone could use us to spam others.
Evidence verifies offline
A sealed page snapshot carries per-file hashes, a platform RSA signature, and a public timestamp (TSA). Even if you don't trust us, you can verify offline that a snapshot was taken at that time and not modified since.
Where it runs, how it's protected
Location
Monitoring probes and the database live in a Hong Kong datacenter with direct connectivity to most of mainland China and overseas. Built-in vantage points in Hong Kong and the mainland.
In transit
Console and API are HTTPS end to end (TLS 1.2+) with auto-renewed certificates. Cookies marked Secure / HttpOnly / SameSite.
Deploy and rollback
Every release runs a full syntax check and DB-migration self-check, then switches the directory atomically; the last 3 versions are kept, and any problem can be rolled back within a minute.
Data retention
Per-check details are kept for 30 days, then rolled up into daily summaries kept long-term; incident history is kept long-term. A deleted site can be restored from Trash within 30 days, then is purged for good.
Self-monitoring
Every cron run is recorded on the platform health panel; a stopped task is noticed immediately — the monitoring system is itself monitored.
Vulnerability report
Found a security issue? Email support@my.webchecks.site with "security" in the subject. We reply within 48 hours and credit you after the fix.
More questions? Just ask.
Support: support@my.webchecks.site, replies within 24 hours on workdays.