Checks (HTTP & Outbound Monitoring)
Have Ionhour actively probe your websites, APIs, and endpoints on a schedule from multiple regions.
Checks are outbound monitors. Instead of waiting for your service to contact Ionhour, Ionhour reaches out and calls your endpoint — a website, an API, or any HTTP URL — on a schedule and verifies the response.
Checks vs. Jobs
Checks probe an endpoint you give Ionhour. If instead you want your own service, script, or cron job to notify Ionhour that it ran successfully, see Jobs — that's the inbound heartbeat model.
The Checks list
The Checks page shows every outbound check in your project or workspace.
- Create Check — opens the check creation form.
- Status filter — narrow the list to a specific status, with a live count for each.
- Search — filter by name.
- List / Grid toggle — switch between a sortable table and a card grid. Both show the same information.
In table view, each row shows:
| Column | What it shows |
|---|---|
| Name | The check's name, a colored status dot, and its project underneath |
| Schedule | How often the check runs |
| Signals | A compact history bar of the most recent probe results |
| Last ping | How long ago the last probe completed |
Click Name or Last ping to sort by that column. Click a row to open the check's detail page.
Every row and card has a menu with:
- Edit — change the check's configuration
- Clone — create a copy of the check as a starting point for a new one
- Transfer — move the check to a different project
- Clear events — permanently delete the check's recorded probe history
- Delete — remove the check
If any checks in the list are health monitors for a Dependency rather than a regular project check, a Show dependency checks toggle appears so you can include or hide them.
Clearing events and deleting are permanent
Clearing a check's events wipes its probe history. Deleting a check removes it entirely. Neither action can be undone.
Creating a check
Name it and set the URL
Give the check a descriptive name (e.g. "Marketing site" or "Payments API health") and enter the http:// or https:// URL Ionhour should probe.
The URL can't be changed after the check is created. If it changes, create a new check or clone this one and update the URL.
Set the check interval
Choose how often Ionhour probes the URL, from your plan's minimum interval (commonly 5 minutes) up to once an hour. New checks default to every 5 minutes.
Configure the HTTP request
Set the method (GET, HEAD, POST, PUT, or PATCH), a request timeout (1–15 seconds, 8 seconds by default), and the expected status range — the minimum and maximum HTTP status codes that count as a healthy response (200–399 by default). Anything outside that range counts as a failure.
Choose whether to follow redirects (and how many hops to allow, up to 3), and whether to block HTTPS-to-HTTP downgrades so a redirect can't silently drop your endpoint onto an insecure connection.
Set failure and recovery thresholds
Outbound checks don't open an incident on the very first failed probe. Instead, set:
| Setting | Meaning | Default | Range |
|---|---|---|---|
| Open incident after | Consecutive failed probes before the check is marked down | 3 | 1–10 |
| Resolve after | Consecutive successful probes before the check is marked healthy again | 2 | 1–10 |
This protects you from noisy alerts caused by a single dropped request or a brief network blip.
Choose probe regions
Pick one or more regions Ionhour should probe from — at least one is required. A new check starts with a single default region selected; add more to get a global view of availability.
Why more than one region helps
A single region can't tell the difference between your service being down and a network problem between that region and your service. When a check probes from multiple regions, Ionhour looks for agreement across regions before changing its status — this avoids false alarms caused by one region having a bad network path.
Optionally add custom HTTP headers (up to 10) — useful for API keys or health-check tokens. Headers that could be used to hijack the request, such as Host, Authorization, and Cookie, can't be set this way.
Turn on latency and SSL monitoring (optional)
Depending on your plan, you can also set:
- Latency alert — get notified when response time exceeds a threshold you set (disabled by default).
- SSL expiry warning — for HTTPS endpoints, get warned when the certificate is close to expiring (14 days by default).
Set alerting and organize the check
Pick a down severity (P1, P2, or P3) for incidents this check creates, and optionally mute notifications if you want the check monitored without sending alerts.
Assign the check to a project, and optionally select any Dependencies this check relies on. If you don't see the dependency you need, use the quick-add link to create one without leaving the form.
Click Create Check to save.
Linking a check to a Dependency
Checks can be tied to a Dependency in two ways:
- As the Dependency's health monitor — when you create a check directly from a Dependency's page, that check becomes the thing that determines whether the Dependency itself is up or down.
- As a consumer of a Dependency — on any regular check, select the Dependencies it relies on (for example, a shared third-party API). If that Dependency goes down, this check's incident is attributed to that root cause instead of being raised as an unrelated outage.
Managing an existing check
Open a check to see its detail page, with Refresh, Probe (dispatch an on-demand probe right now, without waiting for the next scheduled run), and Pause / Resume in the header, plus the same Edit / Clone / Transfer / Clear events / Delete menu from the list. Below that, the page is split into three tabs, each with its own sidebar:
- Overview — a health summary and Response Time / Probe Reliability charts. Its sidebar shows per-region probe status, any linked Dependencies, and a notifications summary.
- Integration — a read-only recap of the check's configuration. Where available on your plan, its sidebar also shows SSL certificate status and a live status badge you can copy as a snippet to embed elsewhere.
- Events — the check's recent probe history.
Pausing a check
A paused check stops probing and won't open new incidents until you resume it. Use this for planned maintenance or endpoints you're temporarily not monitoring — see Maintenance Windows for a more structured way to pause monitoring during planned work.
Next Steps
Jobs (Heartbeat Monitoring)
Monitor cron jobs and scripts that ping Ionhour instead of being probed.
Dependencies
Track external services and attribute incidents to the right root cause.
Alert Routing
Control who gets notified when a check goes down.
Notification Channels
Connect email, Slack, and other channels for alerts.