Uptime Monitoring: Checks
Overview
Use this page to review and manage uptime checks. An uptime check is a configured probe, such as ICMP, TCP port, HTTP, DNS, SSH, or TLS, that the platform runs on a fixed interval against a host, port, or URL you specify, then reports back whether the target responded correctly. The Checks page gives you an at-a-glance view of which monitored endpoints are currently healthy and which are failing, without digging into logs or external tools.
Before a check appears here, you create it, either individually with New Check or in bulk with Import, and give it an endpoint to monitor. Once checks run, their status feeds the dashboards, incidents, and maintenance views elsewhere in Uptime Monitoring, making this page the entry point for configuring new coverage and for triaging failures that surface downstream.
Key concepts
- uptime check - A configured probe that runs on a schedule against a host, port, or URL to test whether it's reachable and responding correctly. (related: Uptime Monitoring: Dashboards)
- Service Type - The protocol or mechanism the check uses to test its target, such as ICMP Ping, TCP Port, HTTP, DNS, SSH, or TLS.
- Group - A logical collection of checks you can filter by, used to review a related subset of checks instead of the full inventory.
- tag - A keyword attached to a check, such as a protocol name or an environment like Production, that you can click under TAGS to quickly filter the list.
When to use it
- To get a quick health snapshot of all configured uptime checks before investigating further.
- To find out why a specific check is failing, using the status detail line instead of external logs.
- To filter the check list by environment, service type, group, or tag before editing or triaging a subset.
- To add monitoring coverage for a new endpoint, either one check at a time or in bulk via import.
- To pause, duplicate, publish, or remove checks as systems under test change or get decommissioned.
Before you begin
- Know the host name, IP address, port, or URL you want to monitor, and which protocol applies to it (ICMP, TCP, HTTP, DNS, SSH, or TLS).
- If you plan to filter by Environment or Group, the checks you're looking for must already have those values set; assign them when creating or editing the check.
- If you plan to use Import, have a JSON file formatted for bulk uptime-check import ready beforehand.
- At least one check must exist for the table to show data; otherwise it displays the empty state until you create one with New Check or Import.
Common workflows
Triage a failing check
Persona: Load-test operator
- Review the Issues KPI card to see how many checks currently have problems.
- Expect: The card shows a count, for example 4, of enabled checks that are Degraded or Unhealthy.
- Click the Issues KPI card.
- Expect: The table filters down to only the checks with Issues, and the card switches to its active style.
- Read the one-line detail under the failing check's STATUS.
- Expect: The exact failure reason, such as a connection failure, is visible without opening the check.
- Click Trigger Now on the check's row.
- Expect: The check runs at once and the row shows the new result. A Repository or API Exposure check runs in the background instead, and a notice says so.
- For a Repository or API Exposure check, click Refresh after the scan ends.
- Expect: The table and KPI cards update to reflect the check's latest result.
Verify: The check's STATUS reads Healthy and the Issues count has decreased by one; if it still reads Unhealthy, the underlying endpoint problem described in the detail line hasn't been resolved yet.
Scope the check list to one environment and protocol
Persona: Load-test operator or admin
- Select an environment, such as Production, in the Environment dropdown.
- Expect: The table narrows to checks assigned to that environment, and a removable filter pill appears above the table.
- Click a protocol tag, such as TCP, under TAGS.
- Expect: The table narrows further to checks carrying that tag, and the chip switches to its active style.
- Click Clear all when you're done.
- Expect: Every filter resets and the full set of checks reappears.
Verify: The Checks count in the table header matches the number of rows shown at each filtering step, confirming the filters are being applied.
Add monitoring coverage for a new endpoint
Persona: Admin
- Click New Check.
- Expect: The check creation page opens.
- Configure the check's name, Service Type, endpoint, and interval, then save it.
- Expect: The new check is created and you return to the Checks list.
- Confirm the new check appears in the table.
- Expect: The Total Checks and Enabled KPI counts each increase by one.
Verify: The new check's NAME, TYPE, ENDPOINT, and INTERVAL show the values you entered, and its STATUS begins reporting after its first scheduled run.
Steps
Step 1
Open Uptime Monitoring > Checks.
Expected result: The page loads showing the Uptime Checks header, summary KPI cards (Total Checks, Healthy, Issues, Enabled), the Filters panel, and a table of currently configured checks with their status, name, type, endpoint, interval, environment, tags, last check time, and response time.
This is the starting point for reviewing and managing every uptime check configured in the platform.
- Refresh, Import, and New Check sit in the page header.
- KPI cards show 8 Total Checks, 4 Healthy, 4 Issues, and 8 Enabled.
- The Filters panel offers Search, Environment, Service Type, and Group, plus tag chips under TAGS.
Field reference
| Field | Purpose | Format / Validation | Required | Default |
|---|---|---|---|---|
| Search | Filters the check list to rows whose name or endpoint contains the typed text; use it to jump straight to a known host or check name instead of scrolling the full list. | Free text | No | - |
| Environment | Narrows the list to checks assigned to one environment; choose All to see checks across every environment, or a specific environment to review only that deployment's monitoring coverage. | Dropdown, single select | No | All |
| Service Type | Narrows the list to checks using one monitoring protocol, such as TCP Port or ICMP Ping; pick a specific type when you only want to review one kind of check instead of the full mixed list. | Dropdown, single select | No | All |
| Group | Narrows the list to checks assigned to one group; use it to review a logical subset of checks instead of the entire inventory. | Dropdown, single select | No | All groups |
Column reference
Select the NAME, TYPE, INTERVAL, ENVIRONMENT, LAST CHECK, or RESPONSE header to sort the table by that column; select it again to reverse the order. When your role may publish to the LoadGen Exchange, a column of tick boxes comes first, for publishing several checks at once.
| Column | What it shows | How to read it |
|---|---|---|
| STATUS | Shows the verdict of the check's latest run. | Healthy means the run passed within the check's thresholds. Degraded means the run passed but took longer than the check's Warning Threshold, carried a warning (for example vulnerable packages on a repository scan), or the SSL certificate expires within the warning days (30 by default). Unhealthy means the run failed. Maintenance means the check is in a maintenance window, Dep. Down that a check it depends on is down, and Unknown that it has not run yet. The line underneath states the specific reason without opening the check. |
| NAME | Identifies the check and its category. | Click the name to open the check for editing; the line beneath it shows which group or protocol category the check belongs to. Labels next to the name: Disabled (the check is switched off), Alerts off (no alert profile fires for it), No datasource or Datasource error (its results cannot be stored; point at the label for the reason), and PowerShell or Plugin for script and custom plugin checks. |
| TYPE | Shows which monitoring protocol the check uses. | Use it to confirm what kind of probe produced the STATUS result. |
| ENDPOINT | Shows the monitored target. | Confirms exactly what the check is probing; for port-based checks, the value after the colon is the port being tested. |
| INTERVAL | Shows how often the check runs. | A shorter interval detects outages sooner but runs the check more often; a longer interval reduces load but delays detection. |
| ENVIRONMENT | Shows the environment the check is assigned to. | The same values the Environment filter offers; a dash means no environment is set. |
| TAGS | Shows the check's tags. | Up to three tags show; +N stands for the others, and pointing at it lists them. |
| LAST CHECK | Shows when the check last ran. | Never means the check has not run yet. An Other installation mark under the time means the last result was written by another installation that shares the same results store. Such a result is read when this appliance's API starts, and a disabled check is not refreshed until the API starts again. |
| RESPONSE | Shows the response time of the latest run. | Green under 200 ms, amber from 200 to 499 ms, and red from 500 ms. |
| ACTIONS | Holds the row actions. | Edit, Trigger Now, Duplicate, Publish to the LoadGen Exchange..., the Enable/Disable toggle, and Delete. Repository Health checks add Repositories and API Exposure checks Exposure report: each opens that check's own results table. |
Controls reference
Refresh
Reloads the check list and KPI counts from the latest data.
When to use: Use after you expect a check's status to have changed, for example after Trigger Now, and want the table and KPI cards to reflect it without leaving the page.
Side effects: Read-only: reloads displayed data, makes no changes to any check.
Import
Opens the Import from JSON flow to add checks in bulk from a prepared file.
When to use: Use when you need to create many checks at once instead of one at a time, for example when rolling out monitoring for a new environment.
Side effects: Mutating: successfully importing a file adds new checks to the list.
New Check
Opens the check creation page.
When to use: Use to add a single new uptime check for a host, port, or URL that isn't monitored yet.
Side effects: Mutating once you complete and save the new check; opening it alone makes no change.
Total Checks (KPI card)
Shows the total number of configured checks and, when clicked, resets every active filter.
When to use: Use to clear Search, Environment, Service Type, Group, and tag filters in one click and return to the full list.
Side effects: Read-only: changes only the filter view, not any check's data.
Healthy (KPI card)
Shows how many enabled checks are Healthy, and when clicked, filters the list to only those checks. A disabled check is never counted as Healthy.
When to use: Use to confirm which endpoints are currently fine before focusing attention on the failing ones.
Side effects: Read-only filter toggle.
Issues (KPI card)
Shows how many enabled checks are Degraded or Unhealthy, and when clicked, filters the list to only those checks. A disabled check is never counted as an issue.
When to use: Use as the starting point for triage: this isolates every check that needs attention.
Side effects: Read-only filter toggle.
Enabled (KPI card)
Shows how many checks are actively scheduled to run, and when clicked, filters the list to only enabled checks.
When to use: Use to find disabled checks by exclusion, or confirm that a check you expect to be running is enabled.
Side effects: Read-only filter toggle.
Tag chip (e.g. Production, TCP)
Toggles the tag on as an active filter; the list narrows to checks carrying that tag, and the chip switches to its active style.
When to use: Use to combine quick keyword filters, protocol tags like TCP or HTTP, or custom tags like Production or Demo, alongside the Environment, Service Type, and Group dropdowns.
Side effects: Read-only: changes the filter view only. Click the chip again to remove it.
Clear all
Removes every active Search, dropdown, and tag filter at once.
When to use: Use once you're done triaging a filtered subset and want to see the full check inventory again.
Side effects: Read-only: resets the filter view only.
Edit (row action)
Opens the selected check for editing.
When to use: Use to change a check's endpoint, interval, environment, group, tags, or other settings.
Side effects: Mutating only if you change and save settings on the edit page; opening it alone makes no change.
Trigger Now (row action)
Runs the check once, outside its schedule.
When to use: Use right after fixing an underlying problem to confirm a check recovers, or when you need a current result without waiting.
Side effects: Mutating: most checks run at once, and the row shows the new result. Repository and API Exposure checks run in the background: a notice says so, and the result shows once the scan ends; click Refresh to see it.
Duplicate
Creates a disabled copy of the check, named after the original with "(Copy)" added.
When to use: Use to quickly create a similar check, for example the same host on a different port, without re-entering every setting.
Side effects: Mutating: adds the disabled copy to the list immediately. Open the copy, check its settings, and enable it when it is ready.
Publish to the LoadGen Exchange... (row action)
Shares the check on the LoadGen Exchange. To publish several checks together, tick them in the first column and use the same button above the table. PowerShell and custom plugin checks cannot be published: their publish icon is greyed out and says why when you point at it.
When to use: Use when you want to share a check you've finished configuring through the LoadGen Exchange.
Side effects: Mutating: publishes a copy of the check to the LoadGen Exchange; the check itself does not change. The action shows only when your role may publish.
Enable/Disable toggle (row action)
Turns the check's scheduled runs on or off without deleting it.
When to use: Use to pause monitoring for a system under planned maintenance or decommissioning, and re-enable it when monitoring should resume.
Side effects: Mutating: a disabled check stops running on its interval, shows Disabled next to its name, and no longer counts toward the Enabled, Healthy, or Issues KPI cards; it keeps its configuration and history.
Delete (row action)
Permanently removes the check after you confirm in the Delete Check dialog.
When to use: Use when a check is no longer needed, for example after decommissioning the monitored host.
Side effects: Mutating and irreversible: the check and its configuration are removed from the list.
Clear selection
Exits bulk-selection mode, used for publishing multiple checks at once, without publishing anything.
When to use: Use if you started selecting checks to publish and decide not to proceed.
Side effects: Read-only: clears the current selection only.
Verify the result
When review and management is working as expected, the table lists every check matching your current filters, and the Checks count in the section header matches the number of visible rows. Each row's STATUS shows the verdict of its latest run, with a one-line reason under any check that isn't Healthy. The KPI cards at the top, Total Checks, Healthy, Issues, and Enabled, reflect the same totals as the table beneath them; Healthy and Issues count enabled checks only. If a check you expect to see is missing, the first thing to check is whether a Search term, Environment, Service Type, Group, or tag filter is still active.
Troubleshooting
- Symptom: A check's STATUS stays the same right after you click Trigger Now. Fix: For a Repository or API Exposure check this is expected: the run continues in the background, as the notice says. Click Refresh after the scan ends. Other checks show the new result at once; if STATUS did not change, read the reason line under it.
- Symptom: A check you know exists doesn't appear in the table. Fix: Check for an active Search term, Environment, Service Type, Group, or tag filter shown as a pill above the table, and click Clear all to reset.
- Symptom: A check no longer runs on its schedule. Fix: Check whether it's been disabled; the enable/disable row action pauses scheduled runs without deleting the check, and it stops counting toward the Enabled KPI card while off.
- Symptom: An uploaded file through Import doesn't add any checks. Fix: By default, one row with errors stops the whole import and nothing is added. Fix the rows the review lists, or tick Skip rows with errors to import only the valid ones.
- Symptom: A check can't be published. Fix: PowerShell and custom plugin checks cannot be published to the LoadGen Exchange; point at the greyed-out publish icon to see why. If no publish action shows at all, your role does not include publishing; ask an administrator.
Related articles
- Next step: Uptime Monitoring: Dashboards - visualize and group check results into dashboards once checks are configured
- See also: Uptime Monitoring: My dashboard - see a personalized view of the checks relevant to you
- Next step: Uptime Monitoring: Incidents - track the incidents that failing checks open
- See also: Uptime Monitoring: Maintenance - schedule maintenance windows so expected downtime doesn't show as a check failure