Questions & answers

The heartbeat core is the same idea. Your job pings a URL, and silence means trouble. So if that is all you need, those are good tools and Healthchecks.io is open source. What PulseWatch adds is a metrics layer on top of one combined dashboard. Attach ?rows=1400 to a ping and set a floor, a ceiling or a 14-run baseline, so a job that finishes but does nothing still alerts. Incident timelines, latency p95, SSL expiry and status pages all read from the same checks. This is a small independent project. There is no sales team, and the limits on the pricing page are the real ones.

Alerts run from a single worker process backed by Postgres. If that process restarts it picks up from stored state, so a short outage delays alerts rather than dropping them. A longer outage on our side means checks are not running during it, and we would rather say so than imply otherwise. Two things help: attach more than one channel, and treat a critical job’s own success as the real source of truth. This is not a redundant multi-region system today.

Yes. A monitor can use a plain interval (every N minutes/hours/days) or a full cron expression with an explicit timezone, for example “every weekday at 07:00 Europe/Paris”. You also set a grace window so a slightly slow run does not trip a false alert. Cron schedules are a Pro feature; see the ping docs for timezone gotchas.

One heartbeat (a single cron job or script) or one uptime check (a single URL) is one monitor. Paused monitors still count against your plan until you delete them. Free includes 3, Pro 25, Business 100.

Add numeric query parameters to a success ping, like ?rows=1400&errors=2, or POST a small JSON body. Run duration is recorded for you as duration_ms whenever a job sends a /start ping before its success ping, so you can put a ceiling on how long a job may take without measuring it yourself. Then define rules on the monitor: a floor (rows ≥ 1000), a ceiling (errors ≤ 5), or a baseline on Pro (value dropped more than N% below the median of the last 14 runs. That is a statistical floor, not anomaly detection and not AI. A configured metric that goes missing counts as a violation too. The ping still registers as received, because the job did run, but the monitor goes down on the violation until a compliant ping clears it. Full details in the ping docs.

They answer different questions. A repeat alert says “this is still broken” and fires on the interval you set, measured from the last alert, for as long as the monitor stays down. It is off by default, and 15 minutes is the shortest interval accepted. A new-error-type alertsays “something different is broken now” and fires the first time a stack trace with an unfamiliar fingerprint arrives, even while the monitor is already down. That is deliberate: a job that was timing out and starts throwing a null dereference is new information. Those are capped at one per monitor per minute. Full timeline in how alerting works.

An incident opens when the monitor goes down and resolves when it returns to up. Nothing needs clicking. The duration is measured from the first failure to the recovery, not from when the alert was sent, so setting a delay before alerting does not make an outage look shorter than it was. If a monitor recovers and fails again within five minutes, the existing incident reopens rather than a second one being created, so a flapping job gives you one incident instead of a dozen. Manual incidents, the ones you write yourself for a status page, are closed by you.

Yes. That is what webhook channels are for. You get a versioned JSON payload signed with HMAC so the receiver can verify it, plus native Slack and Discord formatting when you point a channel at their webhook URLs. A common pattern is routing monitor.down straight into an auto-restart or a pager instead of a human inbox. See the webhooks docs for the payload and signature snippets.

For each ping we store the time, the numeric metrics you send, and, if you POST a body, a run-log excerpt up to your plan’s limit (4 KB Free, 16 KB Pro, 64 KB Business). Excerpts are automatically scrubbed for secrets (passwords, tokens, keys, connection strings) before they are stored, on a best-effort basis. We also record the source IP and user agent of the request for security and abuse handling. Do not put personal or sensitive data in ping bodies. Treat excerpts as operational logs. Details and retention are in the privacy policy.

Lemon Squeezy is the merchant of record. They process the card, handle VAT and sales tax, and are what shows up on your statement. PulseWatch never sees your card number. Manage or cancel the subscription from the billing page in the app.

Cancel anytime from the billing page. Your plan stays active until the end of the paid period, then drops to Free. Your data stays put. For refunds, get in touch within a reasonable window and we will sort it out through Lemon Squeezy. Nobody is getting trapped in a plan they stopped using.

Nothing is deleted. If a downgrade leaves you over the new monitor cap, PulseWatch automatically pauses the excess, oldest first, until you are within the limit. The newest monitors keep running. Once you upgrade again, or delete some, you can resume any paused monitor from the dashboard.

Raw pings and uptime-check results are kept for 7 days on Free, 30 on Pro and 90 on Business, then pruned. Daily latency/uptime rollups and state-change history are kept for about a year so long-range charts and MTTR still work. The full retention table is in the privacy policy.

Open Settings and delete your account there. It is a cascading delete that removes your monitors, pings, checks, channels and history along with the account record, per the privacy policy. Export your data as JSON from the same Settings page first if you want a copy.