Every check is a real request from a real machine.
Pulse watches your site from 6 cities around the world, and, if you want, from inside your own network too. This page walks the whole path: where checks run, how results travel, and what happens when something goes quiet. No magic in the middle, and the probe that runs every check is open source.
Checks come from two directions
A check is one question asked on a schedule: does this thing answer, how fast, and does the answer look right.
The first direction is our fleet: machines we run in cities around the world. They check anything the public internet can reach, and they time every step separately, DNS, connect, TLS, first byte, so you see where it hurts, not just that it hurts.
The second direction is a probe you run. A probe is one small program installed on a machine inside your network. It checks the things the internet cannot see: a NAS on a 10.x address, an internal API, the office gateway.
The probe only ever connects outward, over HTTPS. It opens no ports and accepts no connections, so your firewall stays exactly as it is. Both streams land in the same account: one dashboard, one alert pipeline, one history.
One Linux or PowerShell line installs the probe. It is the same open-source binary our own fleet runs.
What the probe actually does
The loop is deliberately boring, and it never changes:
Every 30 seconds it asks Pulse over HTTPS which monitors it owns. Config travels down that connection; nothing travels in. Then it runs the checks locally, on your machine, against your targets.
Results ship back in gzipped batches every few seconds. Gzip just means the batch is compressed before it leaves, so a probe watching a hundred targets still sips bandwidth.
When the uplink drops, the probe keeps checking and buffers up to 10,000 results in memory. The moment the link returns, it ships the backlog. A short outage between you and us leaves no hole in your history.
Honest limits: the buffer lives in memory, so a probe restarted mid-outage loses what it was holding, and past 10,000 results the oldest are dropped first. You can read the exact code in ship.go.
Two kinds of silence
Silence is ambiguous. Your target might be down, or the machine reporting on it might be. Pulse treats those as two different facts, because they are.
Target down: the probe is fine and keeps reporting, its checks just fail. After a streak of consecutive failed checks, 3 by default and you can change it per monitor, the monitor flips and an alert goes out. One bad sample never pages you.
Probe offline: results stop arriving at all. Pulse does not pretend it still knows. Your monitors hold their last state and are marked stale in the panel, and you get one probe-offline alert, 5 minutes of silence by default, instead of a false page for every monitor that probe carried.
When the probe comes back it backfills what it buffered, so the record shows what really happened, not what a dashboard guessed.
The same rule runs everywhere in Pulse: a day with no data is a grey bar, a bucket with no samples is a gap in the chart, and an unknown is never painted green or red.
That is the whole system.
Pulse is in alpha, actively built, and free: 100 monitors at 15-second intervals, no card. The probe is MIT-licensed and the source is on GitHub, so you can read exactly what runs on your machine before you run it. If something here reads wrong, or you hit an edge we missed, tell us on Discord.