Uptime Monitoring: Dashboard

Overview

Use this page to monitor the real-time health and availability of configured uptime checks. The dashboard aggregates the results of your checks into six KPI summary cards (Total Checks, Healthy, Degraded, Unhealthy, Open Incidents, and Overall Uptime) and shows one card per check, so you can assess service availability at a glance without navigating into individual check records. This page is the fleet page: it covers every check. Uptime Monitoring > My dashboard opens your personal default dashboard when you have one, else the appliance default dashboard, else this page.

Uptime checks are created and configured on the Uptime Monitoring: Checks page. The dashboard consumes those check results and surfaces incidents, which are tracked in full on the Uptime Monitoring: Incidents page. An incident opens only when a check's run fails and the check's Failure Mode says so; a Degraded check never opens one. The Open Incidents card counts the open incidents of enabled checks.

On this page you can filter the check cards by environment, service type, and tenant; choose the period the uptime figures cover; refresh data on demand or automatically; use the KPI cards as quick filters; open the Analytics panel of a check; and enable or disable specific checks without leaving the dashboard.

Key concepts

• uptime check - A configured probe that tests a specific endpoint at a regular interval using a defined protocol (for example SSH Banner or REST API). Each check produces a status classification, a response-time measurement, and an uptime fraction on every poll cycle. (related: Uptime Monitoring: Checks)
• check status - The verdict of the check's latest run: Healthy (the run passed within the check's thresholds), Degraded (the run passed but took longer than the check's own Warning Threshold, or carried a warning, for example vulnerable packages on a repository scan, or the SSL certificate expires within the warning days, 30 by default), or Unhealthy (the run failed). A card can also read Maintenance (the check is in a maintenance window and is skipped), Dep. Down (a check it depends on is down), Unknown (no verdict yet) or Disabled. Status is shown as a label and a color-coded top bar on each check card. (related: Uptime Monitoring: Incidents)
• incident - A record that opens automatically only when a check's run fails, and only once the check's Failure Mode says so: Immediate (the default: the first failure), after a number of failures in a row (3 by default), or a number of failures within a time window. A Degraded run never opens an incident, and neither does a manual run. The incident closes automatically on the first passing run (a Degraded run passes too) or after the number of passing runs the check is set to require. It also closes when the check is deleted, and you can close it by hand with Resolve manually on the Incidents page. (related: Uptime Monitoring: Incidents)
• service type - The protocol or method the check uses to probe the endpoint, such as SSH Banner, REST API, SMTP, DNS, or certificate validation. The Service Type filter on this page narrows the check cards to checks of one protocol family. (related: Uptime Monitoring: Checks)
• uptime fraction - The ratio of successful polls to total polls in the selected period, displayed as both a percentage and a count in parentheses (for example 99.97% (2879/2880)). It measures how often the endpoint was reachable during the window.

When to use it

• Checking at a glance whether all monitored services are Healthy before or after a deployment.
• Identifying which specific checks contributed to an elevated Open Incidents count.
• Filtering by environment or tenant to assess availability for a specific segment of your infrastructure.
• Temporarily disabling an individual uptime check during planned maintenance without navigating to the Checks configuration page.
• Reviewing the license usage banner to determine how many of your licensed endpoint slots are consumed.
• Spotting slow-responding endpoints by comparing color-coded last-response times across check cards.

Before you begin

• At least one uptime check must be configured. If none exist, the Check Status Overview section shows a 'Create your first check' link instead of check cards; it opens the new-check wizard. You can also configure checks on the Uptime Monitoring: Checks page.
• Your account must have access to the Uptime Monitoring module. If the Uptime Monitoring section is absent from the sidebar, contact your administrator to verify your permissions.
• If checks are scoped to specific tenants, the Tenant filter lists the tenant ids set on your checks.

Common workflows

Assess service availability across environments

Persona: Load-test operator or on-call engineer

1. Open Uptime Monitoring > My dashboard. If it opens a dashboard of your own instead of this page, select Uptime Monitoring > Dashboards and then Fleet overview.

• Expect: The page loads showing six KPI cards, a license usage banner, the Check Status Overview grid with one card per configured check, and the Recent Incidents table.

2. Select the target environment from the Environment dropdown, for example Production.

• Expect: The Check Status Overview shows only the cards of checks tagged with that environment; checks from other environments are removed from view.

3. Review the Unhealthy and Degraded KPI cards; if either is greater than zero, select that KPI card to show only the matching check cards, or locate the affected check card by its yellow (Degraded) or red (Unhealthy) top bar in the Check Status Overview.

• Expect: Affected cards are visually separated from Healthy cards by the color of their top bar, making them easy to identify without reading every status label. Select the KPI card again to show every card.

4. Select Analyze on an affected check card.

• Expect: The Analytics: panel for that check opens below all the check cards, showing its uptime and response-time figures for the selected period.

Verify: All enabled check cards show a green top bar and a Healthy status label. The Degraded and Unhealthy KPI counters both display 0. If an incident was expected to have resolved, the Open Incidents counter also displays 0.

Pause a check during planned maintenance

Persona: Administrator

1. Locate the check card for the endpoint undergoing maintenance in the Check Status Overview.

- Expect: The card is visible with its current status badge, uptime fraction, and last response time.

2. Select the Enable / Disable toggle on the check card to disable polling.

• Expect: The page reloads at once. The card turns grey with a dashed border and a Disabled label, and the check stops running. A disabled check is not counted as Healthy, Degraded or Unhealthy.

3. After maintenance completes, select the Enable / Disable toggle again to re-enable the check.

- Expect: Polling resumes at the next scheduled interval and the Last check timestamp on the card begins to advance again.

Verify: The check card returns to an active state with a Last check timestamp that updates on each poll cycle. The Overall Uptime figure stabilizes as post-maintenance successful polls accumulate.

Steps

Step 1

Navigate to the Uptime Monitoring Dashboard: open Uptime Monitoring > My dashboard or, when that opens a dashboard of your own, Uptime Monitoring > Dashboards and then Fleet overview.

Expected result: The dashboard loads displaying six KPI summary cards across the top row (Total Checks, Healthy, Degraded, Unhealthy, Open Incidents, Overall Uptime), a license usage banner showing the fraction of licensed endpoint slots in use, the Check Status Overview grid with one card per configured check, and the Recent Incidents table. Each card shows the check name, a service type badge, a status label such as Healthy, Degraded or Unhealthy, the uptime percentage and poll fraction, the last response time in milliseconds, the environment, an optional tenant row, and the last check timestamp.

Reviewing the KPI row and check cards together gives you the full picture needed to decide whether any endpoint requires immediate attention or investigation.

• The Period dropdown defaults to Last 24 Hours and offers periods from Last 5 Minutes to Last 90 Days, each counted back from now; changing it recalculates the uptime figures for the new window.
• The Environment, Service Type, and Tenant dropdowns all default to showing all items; combine them to narrow the check cards to a specific slice of your infrastructure.
• The Auto checkbox is unchecked by default; enable it so the page refreshes automatically (every 5s, 30s, 1m or 5m; 1m by default) instead of requiring a manual Refresh click.
• Check cards have a color-coded top bar: green for Healthy, yellow for Degraded, red for Unhealthy, blue for Maintenance and grey for Dep. Down, so you can identify problems before reading any text. A disabled check's card is grey with a dashed border.
• Select the Healthy, Degraded, Unhealthy or Open Incidents KPI card to show only the matching check cards, for example only the Degraded ones; select it again to show every card.
• Select a check card to open that check for editing.
• Recent Incidents lists up to 10 of the most recent open incidents; the Uptime Monitoring: Incidents page has the full list.
• The license usage banner shows a progress bar and a percentage; if the fraction is close to your licensed limit (30 endpoints in the example environment), review the Uptime Monitoring: Checks page and delete checks that are no longer needed. Every check uses a seat, enabled or disabled, and deleting a check frees its seat.

Field reference

| Field | Purpose | Format / Validation | Required | Default |

|---|---|---|---|---|

| Period | Sets the time window over which uptime fractions, Overall Uptime, and response-time history are calculated. Every period counts back from now, from Last 5 Minutes to Last 90 Days. A shorter window (Last 24 Hours) shows the most recent performance; a longer window reveals trends and past degradations useful for SLA reporting. Open incidents are counted whatever the period. Use shorter periods for live operational monitoring and longer periods for historical review. | Dropdown | No | Last 24 Hours |

| Environment | Filters the Check Status Overview to show only checks tagged with the selected environment. Use this to isolate Production checks from Staging or other environments when assessing live-service health. | Dropdown | No | All Environments |

| Service Type | Filters the check cards to checks of a specific protocol family. The list is populated dynamically from the check types present on the appliance (for example SSH Banner, REST API, SMTP, DNS). Use this to compare response times or uptime for a single technology independently of others. | Dropdown | No | All Service Types |

| Tenant | Narrows the check cards to checks scoped to a specific tenant. The list shows the tenant ids set on your checks. When a check is not associated with a particular tenant, the Tenant row does not appear on its card. Use this in multi-tenant deployments to view availability for a single customer segment. | Dropdown | No | All Tenants |

| Auto | When checked, the dashboard refreshes data automatically at the interval you pick next to it (5s, 30s, 1m or 5m; 1m by default) so KPI cards and check cards stay current without manual clicks. When unchecked, the data reloads only when you click Refresh or change the period; the 'Updated X ago' label keeps counting either way. Enable Auto during live incident response to watch status changes in real time; leave it unchecked when examining a fixed historical snapshot to prevent the period from shifting. | Checkbox | No | unchecked |

Column reference

| Column | What it shows | How to read it |

|---|---|---|

| Total Checks | Reports the count of your configured uptime checks, disabled ones included. | Healthy, Degraded and Unhealthy count enabled checks only, so a disabled check keeps their sum below Total Checks. The Environment, Service Type, and Tenant filters narrow the check cards below. |

| Healthy | Reports the count of enabled checks whose latest run passed within the check's thresholds. | A disabled check is not counted, so Healthy can stay below Total Checks while everything is fine. Everything is fine when Degraded and Unhealthy are both 0. Select the card to show only the Healthy check cards. |

| Degraded | Reports the count of enabled checks in a Degraded state: the latest run passed but took longer than the check's own Warning Threshold, or carried a warning (for example vulnerable packages on a repository scan), or the SSL certificate expires within the warning days (30 by default). | Any value above 0 indicates at least one endpoint is slow or needs attention. A Degraded check never opens an incident. Select the card to show only the Degraded check cards, then select Analyze on a card to assess whether the slowness is sustained or a transient spike. |

| Unhealthy | Reports the count of enabled checks whose latest run failed. | Any value above 0 signals an outage. Select the card to show only the Unhealthy check cards, and navigate to Uptime Monitoring: Incidents for the full incident record and resolution history. |

| Open Incidents | Reports the count of open incidents of enabled checks, whatever the chosen period. | An incident opens only on a failed run, once the check's Failure Mode says so, so a check can be Unhealthy without an open incident; a Degraded check never has one. A value of 0 confirms no incident is open. Select the card to show only the checks with an open incident. |

| Overall Uptime | Reports the average uptime of the enabled checks over the selected period. | 100.0% means every poll of every enabled check succeeded during the period. The value is green from 99%, amber from 95% to under 99%, and red below 95%. |

| Uptime (check card) | Shows the uptime percentage and raw poll fraction for an individual check in the selected period. | The fraction shows how many polls succeeded out of the total polls attempted. A denominator that seems low relative to the period may indicate the check was disabled for part of the window. Collecting data... means runs are due in the period but no result is in yet. |

| Last response (check card) | Shows the most recent response time recorded for the check, colored on a fixed scale. | Green: under 200 ms. Amber: 200 to 499 ms. Red: 500 ms or more. The color only flags the response time; whether the check is Degraded follows from its own Warning Threshold and shows in its status label. The HTTP status code (for example 200) confirms the server returned a success response, not just a TCP connection. |

| Incidents (check card) | Shows the check's open incidents, for example "1 open". Select it to open the Incidents page. | When the check is Unhealthy but its Failure Mode has not opened an incident yet, the row reads Incident pending with the failures counted so far, or No active incident. |

| Missed (check card) | Shows how many runs were due in the selected period but left no result, for example "3 checks". | The row appears only when runs are missing. Check that the check runs on its interval. |

| Environment (check card) | Shows the environment tag assigned to the check, for example Production. | Use this to confirm you are looking at the correct environment when filters are set to All Environments. |

| Tenant (check card) | Shows the tenant the check is scoped to. This row appears only on checks that are associated with a specific tenant; it is absent on checks that monitor shared or unscoped endpoints. | If the row is missing, the check is not scoped to any individual tenant. |

| Last check (check card) | Shows the date and time of the most recent completed poll for the check. | If the timestamp is significantly older than the current time, the check may be disabled, its polling interval is long, or the agent responsible for polling is unreachable. |

| Labels (check card) | No datasource or Datasource error next to the service type: the check has no datasource for its results, or its datasource fails. Other installation under the last check time: the last result shown was written by another installation that shares the same results store. | Point at a label to see the reason. An Other installation result is read when this appliance's API starts; a disabled check is not refreshed until the API starts again, while an enabled check replaces it with its own result on its next run. |

Controls reference

Refresh

Immediately reloads all dashboard data, updating the six KPI cards, the license usage banner, every check card, and Recent Incidents with the latest poll results for the selected period.

When to use: Use when Auto is unchecked and you want a single on-demand update, or when you suspect the displayed data is stale after a recent configuration change.

Side effects: Read-only data fetch; no checks are modified. The 'Updated X ago' timestamp resets to reflect the new load time after the request completes. The credentials banner loads with the page and is not reloaded; reload the page to update it.

Auto

Toggles automatic periodic refresh of the dashboard on or off. When it is on, pick the interval next to it: 5s, 30s, 1m or 5m (1m by default).

When to use: Enable during live incident response or active monitoring shifts so the page stays current without manual interaction.

Side effects: When enabled, the page refreshes at once and then at the chosen interval. The 'Updated X ago' label keeps counting either way and resets on each refresh; turning Auto off only stops the automatic refreshes. This control does not modify any check data.

Toggle Analytics (per check card)

Select Analyze on a check card to open the Analytics panel for that check. One panel, headed Analytics: and the check name, opens below all the check cards. It shows the check's Uptime, Total Checks (the runs in the period), Avg Response and P95 Response figures, the Min, Avg, P95 and Max response times, a passed and failed bar when runs failed, its own period buttons, and Ask AI about this check where AI analysis is available to you. Select Analyze on another card to show that check in the panel instead.

When to use: Use when you need to examine the performance trend of one specific check without navigating to a separate analytics page.

Side effects: Read-only; opens or closes the panel. No data is modified and the check cards are not affected.

Enable / Disable check (per check card)

Toggles the enabled state of the uptime check directly from the dashboard card, pausing or resuming polling for that endpoint.

When to use: Use to temporarily pause a check during planned maintenance or a known outage without navigating to Uptime Monitoring: Checks. Re-enable it when the maintenance window ends.

Side effects: Mutating: changes the check's enabled state on the server, and the page reloads at once. A disabled check stops generating new poll results and incidents, and its card turns grey with a dashed border and a Disabled label. Re-enabling resumes polling from the next scheduled interval. A disabled check still uses its license seat.

Hide Analytics (per check card)

Closes the Analytics panel. Select Hide Analytics on the card whose panel is open, or the X in the panel's header.

When to use: Use after reviewing the analytics to tidy the dashboard and restore a full view of all check cards.

Side effects: Read-only; closes the panel. No data is modified.

Create your first check

Opens the new-check wizard, where you configure a new uptime check.

When to use: Visible only when no checks have been configured. Use it to bootstrap monitoring directly from the empty dashboard state.

Side effects: Read-only navigation; no data is created on the dashboard itself. The check is created when you finish the wizard.

Verify the result

When the primary task succeeds, the Uptime Monitoring Dashboard displays the cards of your enabled checks with green top bars and Healthy status labels, and both the Degraded and Unhealthy KPI counters show 0. The Overall Uptime percentage reflects full availability for the selected period and the Open Incidents counter shows 0 if no incidents are open. The 'Updated X ago' timestamp near the Refresh button confirms the data is current. If any check card shows a yellow or red top bar, select Analyze on it to open its Analytics panel and determine whether the problem is sustained. If the Check Status Overview is empty and shows the 'Create your first check' link, no checks have been configured yet. Use that link to open the new-check wizard, or navigate to Uptime Monitoring: Checks to add one.

Troubleshooting

• Symptom: The Check Status Overview is empty and shows 'Create your first check' instead of check cards. Fix: Select Create your first check to open the new-check wizard, or navigate to Uptime Monitoring: Checks and configure at least one uptime check; its card appears on the dashboard and fills in once the check completes a poll cycle.
• Symptom: The Unhealthy or Degraded KPI counter is elevated but you cannot locate the affected check card. Fix: Clear the Environment, Service Type, and Tenant filters by setting each back to 'All' so no checks are excluded from the Check Status Overview, then select the Unhealthy or Degraded KPI card to show only the matching check cards.
• Symptom: The Overall Uptime percentage is lower than expected even though all cards currently show Healthy. Fix: Change the Period dropdown to a shorter window; a longer period includes past failed polls that drag the average down even after all checks have recovered.
• Symptom: A check card's last-response time is shown in amber. Fix: Amber means the last response took 200 to 499 ms; red means 500 ms or more. The color is a fixed scale and does not change the check's status: the status label shows whether the check is Degraded by its own Warning Threshold. Select Analyze on the card to determine whether the slowness is sustained or a transient spike before treating it as an incident.
• Symptom: The license usage banner shows a percentage close to 100%. Fix: Open Uptime Monitoring: Checks and delete any checks that are no longer needed, or contact your administrator to increase the licensed endpoint allocation. A disabled check still uses its seat; deleting a check frees it.
• Symptom: KPI card values do not update after clicking Refresh. Fix: Every period counts back from now, so new results appear on the next refresh. Check the Last check time on the cards: a check runs only at its own interval, and a disabled check does not run at all.

Related articles

• Prerequisite: Uptime Monitoring: Checks - checks must be configured there before the dashboard has any data to display
• Next step: Uptime Monitoring: Incidents - open incidents surfaced by the Open Incidents KPI card are investigated and resolved on this page
• See also: Uptime Monitoring: Maintenance - schedule planned downtime windows to suppress false incidents during maintenance instead of manually toggling checks on the dashboard
• See also: Uptime Monitoring: Reminders - configure credential-expiry reminders that appear as banners on the dashboard when certificates or credentials are nearing expiry
• See also: Service Levels: Dashboard - correlate uptime availability data with SLA objectives tracked in the Service Levels module
• See also: Uptime Monitoring: Dashboards - set the personal default dashboard that Uptime Monitoring > My dashboard opens, or open this page from Fleet overview