Pulseguard
Under Attack?Website Monitoring
Know the moment something breaks.
Uptime, response time, and visual diffing checked from multiple regions, so you hear about a problem before your customers do.
- Between checks
- 60s
- Probe regions
- 5
- History retained
- 90d
- Failures before alerting
- 3
One page tells you whether the site is fine.
Latency from every probe region next to the availability record for the last ninety days: the two questions you actually ask during an incident, answered side by side.
- Frankfurteu-central41ms
- Londoneu-west58ms
- Virginiaus-east112ms
- São Paulosa-east214ms
- Singaporeap-south187ms
Customers should never be your monitoring
Most teams find out a site is down from a support ticket. Checks running from outside your network close that gap.
Checked from where users are
A site that resolves fine from your office can be unreachable from another continent. Probes run from several regions, so a routing or CDN problem shows up as a regional failure rather than a mystery.
Slow counts as broken
Response time is recorded on every check, not just up or down. A page that has crept from 200ms to two seconds is a problem worth seeing before it turns into an outage.
Confirmed before you're paged
A single failed request is usually noise. A check has to fail from more than one region before an incident opens, so an alert means something real.
Changes you didn't ship
Page content is hashed on every pass. When the homepage changes without a deploy behind it, that's a defacement or a bad cache, and it lands on the timeline either way.
The whole certificate path
A check that fails on an expired certificate or a TLS handshake error reports exactly that, instead of a generic timeout you have to reproduce by hand.
A record you can point at
Ninety days of availability per site, kept as evidence: for the incident review, the customer asking about last month, or the SLA conversation.
Every probe records more than a status code
Each check is one request with the whole result kept: what came back, how long it took, and what changed since last time.
Reachability
HTTP status, redirect chain, and connection errors, separated so a 500 never gets filed the same way as a DNS failure.
Response time
Total time to first byte per region, kept per check so a slow trend is visible long before a threshold trips.
Content drift
A content hash per page, compared against the previous pass, using the same mechanism that detects unannounced deployments.
Certificate validity
The TLS handshake is part of the check, so an expiring or misissued certificate surfaces here as well as in SSL Monitoring.
From a domain to a monitored site
Verify a domain once. Everything after that runs on a schedule, without anyone remembering to trigger it.
- 1
Verify the domain
Prove you own it with a DNS TXT record, an HTML file, or a meta tag. Verification is what unlocks scheduled checks. PulseGuard never monitors a domain nobody has claimed.
- 2
Checks start on their own schedule
Probes run on their own cadence, independent of manual scans, so uptime keeps being recorded whether or not anyone is running a security scan that day.
- 3
A failure has to repeat before it counts
One failed request is retried from a different region. Only a failure that reproduces opens an incident, which is what keeps a blip from waking anyone up.
- 4
The incident carries its own history
When one opens, it arrives with the failing region, the status code, the response body excerpt, and the last known-good check, not just a notification that something is wrong.
Website Monitoring, answered.
Checks run every 60 seconds, and a failure has to reproduce from a second region before an incident opens. In practice that means a real outage is confirmed and alerting within about a minute, while a single dropped request never pages anyone.
Stop hearing about downtime from customers.
Verify a domain and the first checks start within the minute.