How monitoring & alerts work · Updated July 13, 2026
Five monitor types: HTTP(S) (a URL returns a healthy status), TCP (a host:port accepts connections), DNS (a domain resolves to the record you expect), Heartbeat (a scheduled job of yours checks in on time, we alert if it goes silent), and Change detection (we tell you when the content of a page changes).
It depends on your plan: every 5 minutes on Free, every 1 minute on Essential, and as often as every 30 seconds on Business. Checks are spread out over each interval rather than all firing at once, so results arrive steadily.
We don't alert on the first failed check: a single blip (a brief network hiccup, a momentary 5xx) shouldn't wake you up. When a check fails, we retry up to two more times, about 10 seconds apart. Only if all three fail do we confirm the outage and send a "down" alert. Heartbeat monitors are the exception: a missed heartbeat is definitive, so there's nothing to retry.
It's inverted monitoring: instead of us pinging your site, your job (a cron task, backup script, scheduled worker) pings a unique URL we give you. If we don't hear from it within its expected window plus a short grace period, we alert you. Great for catching silent failures in things that have no public URL to check, and it means you don't need a separate cron-monitoring tool alongside your uptime monitor. One monitor type, same dashboard, same alert channels.
To a point, yes. A plain uptime ping only proves your server responded, it can't tell you that checkout is throwing errors or that login silently broke after a deploy, because the page can still return a perfectly healthy status code. That's what keyword matching and custom request method, headers, and body (Business plan) are for: assert that specific text appears or disappears in the response, or that an API call returns the shape you expect. It's not full browser-based transaction testing, there's no clicking through a UI, but it catches the "page loads fine but the thing users actually care about is broken" failures that pure uptime monitoring misses entirely.
Discord, Slack, Microsoft Teams, Telegram, Google Chat, email, PagerDuty, Pushover, and generic outgoing webhooks (for Zapier, Make, n8n, or your own server). Available channels and how many you can configure depend on your plan.
You get a Down alert when an outage is confirmed (see above), and a Recovered alert the moment the monitor is healthy again. For a prolonged outage, we also send periodic reminders at 30 min, 1 hour, 4 hours, 12 hours, 24 hours, and 3 days, then we stop, so a long outage doesn't spam you indefinitely.
A daily time range (e.g. overnight) during which non-critical alerts are held back. Recovery notices still come through, and the reminder schedule picks back up once quiet hours end, so you're never left unaware of an ongoing outage, just not pinged at 3 a.m. for it.
If you know a site will be down for planned work, schedule a maintenance window and we'll suppress all alerts for that monitor during it, including recovery and SSL notices. Checks keep running and data keeps recording; only the notifications are paused.
Yes (on plans that include SSL monitoring). We check certificate expiry during regular monitoring and alert you ahead of time so you can renew before visitors hit a security warning. SSL alerts are independent of uptime: a site can be perfectly up and still have a cert about to lapse.
That's flap detection working as intended. When a monitor toggles between up and down repeatedly in a short span (usually a genuinely unstable target, not a clean outage), sending an alert for every flip just buries the signal in noise. So after a few rapid toggles we send one "flap detected" notice and then mute further alerts for that monitor until it settles.
The mute window escalates the longer a monitor stays flaky: the first flap episode mutes alerts for about an hour, and if it keeps flapping the window grows (up to several hours) rather than repeating the same short burst over and over. Once the monitor is genuinely stable again, the escalation resets on its own.
It's an early heads-up. If a monitor changes state again within a few minutes of its last change, before it's toggled enough to trigger full flap suppression, we tag that alert with a small "possible flap" note. It's a hint that the target may be unstable, so you can look into it rather than treating each flip as an independent incident.
No: suppression only kicks in after a monitor has already alerted you several times about its instability, so you're always told first. It quiets the repetitive noise from an unstable target; it doesn't hide the fact that something is wrong. The monitor's full history is always visible on its dashboard page.
Detailed per-check data is retained for a rolling recent window and then rolled up into hourly summaries for long-term history. How far back that history goes depends on your plan: 7 days on Free, 90 days on Essential, and 1 year on Business.
10 on Free, 15 on Essential, and 35 on Business. See the pricing page for the full breakdown of what each plan includes.
It's the share of checks in a given window where your monitor responded healthily. Time inside a scheduled maintenance window isn't counted against you, so planned work doesn't dent your numbers.
Email us at support@impulseye.com , happy to help.
Alerting behaviour (thresholds, timings, and suppression windows) may be tuned over time as we improve reliability. This page describes how the system behaves today.