How monitoring works

Every scheduled probe, from cron tick to tick mark on the strip. No magic — here's exactly what happens and why.

The short version

Produl's monitor runs every minute and checks which of your services are due for a probe. For each, Produl fires a single HTTP request with a timeout, records the result, and moves on. Failed checks can auto-open an incident; recovered services auto-resolve it.

No agents, no webhooks

You don't install anything on your servers to be monitored. Produl just makes HTTP requests to URLs you list — the same ones your users would hit. If a URL is reachable from the public internet, we can probe it.

Check intervals

Each service has its own interval:

Interval	Checks / day	Good for
`1 minute`	1,440	APIs, critical-path endpoints where a 5-minute blind spot is unacceptable.
`5 minutes`	288	The sensible default — detects real outages quickly without hammering your infra.
`10 minutes`	144	Marketing sites, docs, anything that doesn't need sub-minute precision.
`30 minutes`	48	Low-traffic landing pages, partner integrations.
`1 hour`	24	Background services, scheduled reports, things that naturally pulse.

You set the interval when creating or editing a service. Changing it takes effect on the next check — no redeploy, no restart. Historical checks aren't affected.

Wall-clock synchronisation

Every service on the same interval runs at the same wall-clock minute. Concretely:

1-minute services probe at :00 every minute.
5-minute services probe at :00, :05, :10, :15, :20…
10-minute services probe at :00, :10, :20, :30, :40, :50.

This is because “due” is defined globally as a bucket crossing, not as “N seconds since the last check”. Produl asks whether the current wall-clock bucket has changed since the last recorded check — if yes, the service is due.

Why this matters

If you have five services on a 5-minute interval, they all probe simultaneously — not drifting apart as time goes on. Their strips line up visually, so “what happened at 14:05?” gives you a single vertical slice across every service.

What the probe does

One HTTP request, per service, per boundary. By default it's a GET, but you can setHEAD or POSTwhen editing the service. Probes currently run from a single US region (multi-region probing is on the roadmap; for now, treat each result as “reachable from the US internet”).

What counts as “up”

Any HTTP status code in the range [expected_status_min, expected_status_max] — default200–399 — counts as up. This means 301/302 redirects are fine (Produl follows them before checking the final status), and any 4xx/5xx is a failure.

Timeouts

The default timeout is 10,000 ms. If the server takes longer than that to respond, the check is marked down with an error of Timed out after 10000ms. You can raise or lower this in the service's Edit dialog — acceptable range is ~1s to 60s.

Timeouts are real

A slow response that eventually succeeds is still a failed checkif it blew past the timeout. Two consecutive slow responses will trigger an auto-incident — which is almost certainly what you want, because users in the real world don't wait either.

User-Agent

Every request sends a User-Agent header of:

Produl-Status-Check/1.0 (+https://produl.tech)

You can safely filter this out of your analytics, or configure your rate-limiter to exempt it — Produl probes follow redirects but never execute JavaScript, so they'll never be mistaken for real users in your own analytics (we ignore our own tracker calls by UA).

Sync All

The Sync Allbutton on the management page fires an out-of-schedule probe for every non-paused service on that page, in parallel. Results land the same way a scheduled check would — the service's last-checked timestamp updates and a new tick appears on the strip.

Sync All is useful when you've just added a service (to get an immediate first data point) or when you've deployed a fix and want confirmation before the next scheduled interval rolls around.

Boundary auto-sync

When you're actively viewing the management page, Produl also fires a sync automatically the moment a wall-clock boundary hits — so the timer hitting zero genuinely does result in a new check.

Data retention

Individual check results are kept for 95 days. The 90-day uptime aggregate shown on the public page is computed from these results, so you always have comfortable headroom above 90 days of history.

Incidents and their timeline updates are kept indefinitely — useful for long-term SLA reporting and compliance audits. You can delete them manually if you want.

Limits & good defaults

Services per status page: no hard limit today. Realistically, once you pass ~15 rows the public page gets cluttered — consider splitting into multiple pages (e.g. “Customer dashboard” and “Partner API”).
Probe batch size: probes run in parallel batches. A page with 50 services on a 5-minute cadence still finishes well within the minute-long window.
Network egress: every check is a standard HTTPS request — count on about 2–8 KB per probe, dominated by the TLS handshake.

Quick Start

Incidents