How a PulseWatch check actually works
Every result you see comes from a genuine request made by our servers to your endpoint — guarded, timed, evaluated and recorded. Here is the whole journey, step by step.
The end-to-end flow
From the moment you save a monitor to the moment a status page updates.
Configure monitor
Scheduler (every minute)
Claim due monitors
Security guards
Real request
Evaluate
Store check
Incident / alert
Dashboard & status page
1. Add a website or API monitor
You give PulseWatch a URL (or hostname for non-HTTP types) plus how it should be judged: the check interval, a request timeout, the expected HTTP status, and optional settings such as a keyword that must appear in the response or a failure threshold before an incident opens.
Monitors belong to your account only. Database row-level security means nobody else can read your monitors, checks or incidents.
2. The scheduler runs every minute
A database cron job (pg_cron) fires once a minute and asks which monitors are due, based on each monitor's own interval — a 60-second monitor is due every minute, a 300-second monitor every five.
Due monitors are atomically claimed before any request is made, so if two scheduler runs overlap the same monitor is never checked twice at once and no duplicate history is written.
3. Security guards run before any request
Because PulseWatch makes outbound requests on your behalf, every target is validated first. This stops the service from being used to reach private infrastructure.
Parse & validate URL
http/https only, allowed ports
Resolve DNS
server-side resolution
Public address check
private, loopback, link-local and metadata IPs rejected
Make request
timeout + response size cap
Re-validate redirects
every hop checked again
Blocked targets include loopback and private ranges, link-local addresses, cloud metadata endpoints and internal-only hostnames. DNS results are re-checked to defend against rebinding, and every redirect hop is validated again before it is followed. Requests carry a hard timeout and a response-size cap.
4. A real server-side request
PulseWatch then performs an actual HTTP or HTTPS request from its own server runtime — not from your browser. Nothing is simulated, estimated or pre-generated. If a request cannot be made, PulseWatch says so rather than inventing a result.
5. Evaluating the response
The response is judged on its HTTP status against your expected status, the measured response time against the timeout, and, where configured, whether your keyword appears in the response content. DNS and TCP monitor types are evaluated with their own equivalent success criteria where the runtime supports them.
6. Storing the history
Each check is written to your history with its timestamp, up/down outcome, HTTP status code, response time and any error message. Those rows are what uptime percentages, latency charts and status history are calculated from — no averages are invented.
7. Incidents and alerts
A single blip does not have to be an outage. Once a monitor reaches its configured failure threshold, an incident opens with a start time. When the endpoint answers correctly again, the incident closes and its duration is recorded.
Where email alerting is configured, PulseWatch sends a DOWN notification when an incident opens and a RECOVERED notification when it closes, and logs each send.
8. Dashboard and public status page
Your dashboard shows current status, uptime percentage, latest response time, when the monitor was last checked, and the incident timeline. Monitors you explicitly mark as public can appear on a shareable status page that exposes status, uptime and history only — private monitors and full URLs are never leaked.
Runtime limits and SSL certificates — handled honestly
Some checks depend on capabilities the server runtime may not offer, such as raw TCP sockets. When a capability is unavailable, PulseWatch records a runtime limitation and displays it as such. It never records fake downtime for something it could not attempt.
The same applies to TLS: certificate details such as expiry date, days remaining and issuer are captured where the runtime supports certificate inspection. Where it does not, PulseWatch labels the certificate information as unavailable rather than inventing an expiry date.
Frequently asked
- Is the check real?
- Yes. Every result comes from an actual HTTP or HTTPS request made server-side to your URL. PulseWatch never simulates or estimates a result.
- Where does the check run?
- In PulseWatch's own server runtime, not in your browser. That means results are independent of your network or device.
- How often does it run?
- A database scheduler wakes every minute and runs only the monitors that are due, based on each monitor's own interval (for example every 60 or 300 seconds).
- What happens when a check fails?
- The failure is stored with its status code, latency and error. Once a monitor reaches its configured failure threshold an incident opens, and configured email alerts are sent for DOWN and RECOVERED events.
- Does PulseWatch store the response body?
- No. The public one-off checker does not persist anything at all. Monitor checks persist metadata only — timestamp, up/down, status code, response time and any error. Keyword monitors read a size-capped portion of the response purely to test for a match; arbitrary response bodies are never stored.
See it for yourself
Run a one-off check now, or set up continuous monitoring in a minute.