Why you can trust our monitoring (and the limits you should know)

"Trust me, a startup, with the uptime, security and performance data for my site" — that's a fair question to ask. If we're going to watch your site for you, you should know exactly what we're doing, what we can't do, and how to check that we're telling the truth. Here's the unvarnished version.

#What our checks actually do

Everything Vergate reports comes from a check you can read about — the engine that powers our security findings is open source, and every finding carries evidence: the URL, header or payload that triggered it, plus a severity and a likelihood label (observed / likely / possible). We don't emit "trust us, it's vulnerable" — we show you the request that proved it.

The monitoring layer runs on a 60-second scheduler from our backend:

• Uptime checks — HTTP checks from the cloud, the way a user in the world experiences your site, not the way localhost does.
• Threat re-scans — your target is re-scanned on a schedule you choose (15 min to weekly, plan-dependent). New findings are diffed against the last scan so you only get alerted on changes, not noise.
• Exposure checks — public git exposure, open ports, subdomain drift via certificate transparency logs.
• CVE lookups — your profiled technology stack cross-referenced against known vulnerabilities.
• Regression checks — performance, SEO/AEO and accessibility scores tracked over time so a deploy that drops a metric triggers an alert, with the fix suggestions attached.

#Why reports are tamper-evident

Any scanner can print a report. We wanted you to be able to prove a report is what we actually produced. Every downloaded report — PDF or JSON — carries a signature: a keyed hash of the exact report bytes, verifiable through a public endpoint on vergate.dev. If anyone (including us) edits the report after the fact, the signature no longer matches and verification fails. You can send a signed report to a client, a compliance reviewer, or your own records, and prove it hasn't been touched since we produced it.

#Where we are transparent by design

• Open engine — the check logic is source-readable; you can audit how a finding was produced, or reproduce it.
• No lock-in — every report downloads as PDF or JSON. Delete your account and your data goes with it.
• Credentials — connected integrations are encrypted with a key derived from our deployment secrets (Fernet symmetric encryption); API keys are SHA-256 hashed at rest, never stored raw.
• Human-sized facts — no "99.999% uptime" marketing claims about our own infrastructure. If you want the real picture, our admin health dashboard shows actual queue depths, failure rates and resource usage internally.

#The limits we won't pretend don't exist

Trust also means telling you what we can't do:

• No scanner catches everything — including us. We catch the classes of problems automated checks are good at: the top of the attacker checklist. For compliance-grade assurance, hire a professional penetration tester. We say this in our terms and we mean it.
• Cloud checks can't see inside your network — a VPN-only endpoint or a device-specific issue is invisible to us by design. We test from the internet so you get user-perspective results; that's the trade.
• First scan = baseline — the first threat scan on a target reports everything as "new" because there's nothing to diff against yet. That's expected, not a bug: the value starts with the second scan.

#The honest test

Don't take our word for any of this. Run a free scan on your own site — no account needed — and read the evidence on a finding you care about. Every finding shows its work. That's the standard we hold ourselves to, and the one you should hold any tool you trust with your site to.