Health Monitoring

Health Monitoring gives operations and platform teams continuous visibility into server CPU, memory, disk, disk I/O, and agent status so they can catch resource bottlenecks before they become outages.

Private beta

Health Monitoring is private beta only and releases publicly in Q1 2027. Public product navigation and search focus on Certificate, Endpoint, DNS, and Domain Monitoring until public-release planning begins.

When To Use It

  • Use Health Monitoring when a server, virtual machine, or supported host needs resource-level monitoring.
  • Use Endpoint Monitoring when the user-facing risk is whether a URL or application endpoint responds successfully.
  • Use Windows Event Monitoring when the risk is a Windows event log, event ID, event source, or severity pattern.
  • Use Certificate, DNS, and Domain Monitoring when the risk is certificate expiration, DNS behavior, or domain status rather than host-resource pressure.

Supported Systems

During private beta, Health Monitoring installs on supported Linux and Windows Server hosts. macOS is supported for CLI workflows that manage Health Monitoring, but it is not a monitored-host target.

SystemHealth Monitoring supportArchitectures
Linux serversUbuntu 20.04, 22.04, or 24.04 LTS; Debian 10, 11, or 12; RHEL 8 or 9; Rocky Linux 8 or 9; AlmaLinux 8 or 9; and Amazon Linux 2023. Linux hosts need glibc 2.28 or later.x86_64 and arm64
Windows ServerWindows Server 2019 and Windows Server 2022.x64
macOSmacOS 12 or later is CLI-only for Health Monitoring workflows. Use it to manage supported Linux and Windows Server hosts.Intel and Apple silicon

Prerequisites

  • A Bitaic workspace role that can register and manage Health Monitoring hosts.
  • A supported Linux or Windows Server host where the Health Monitoring agent can be installed.
  • Local administrator rights for installation or upgrades, plus a dedicated runtime service identity for ongoing collection.
  • Outbound HTTPS access from the host to Bitaic API and ingestion endpoints.
  • Notification routing for CPU, memory, disk-used, or disk I/O utilization threshold alerts.
Permission requirement

Use Operator access to register and manage Health Monitoring hosts, Viewer access for read-only metrics, and Admin or API-access roles for service-token management. Install or upgrade the agent with local administrator rights; runtime collection uses a dedicated non-interactive service identity.

What Bitaic Checks

  • CPU utilization as health.cpu.utilization_percent.
  • Memory utilization as health.memory.utilization_percent.
  • Disk usage as health.disk.used_percent.
  • Disk I/O throughput as health.disk.read_bytes_per_second and health.disk.write_bytes_per_second.
  • Disk I/O utilization as health.disk.io_utilization_percent.
  • Agent heartbeat age as health.agent.heartbeat_age_seconds.
  • Threshold state for CPU utilization, memory utilization, disk used, and disk I/O utilization.
  • Host identity, telemetry freshness, and agent status.
  • Real-time and historical health metrics in the Bitaic dashboard.

Agent Runtime And Freshness

Runtime areaLaunch behavior
Local privilegesInstallation and upgrades require sudo or root on Linux and local Administrator on Windows Server. Runtime collection reads OS performance counters, /proc, /sys, mount and disk statistics, and agent logs.
Service identityThe agent runs as bitaic-health on Linux and NT SERVICE\BitaicHealthAgent by default on Windows Server. Health Monitoring does not require SSH keys, interactive shell access, kernel modules, packet capture, broad file-content reads, database credentials, or inbound firewall rules.
Network egressRuntime traffic uses outbound HTTPS on TCP 443 to api.bitaic.com and ingest.bitaic.com. Install and update workflows may also reach downloads.bitaic.com. Standard HTTPS proxy settings may be used where required.
Collection interval and bufferCore metrics collect every 60 seconds by default. Configured intervals can be 30 to 300 seconds. During temporary egress loss, the agent keeps a 24-hour local oldest-drop buffer.
Freshness statesTelemetry is fresh when the latest heartbeat and metric sample are no more than two collection intervals old, stale after three missed intervals, and unknown before first telemetry or when Bitaic cannot reconcile host identity.
Overhead guardrailsDefault collection targets less than 1% sustained average CPU, less than 150 MB resident memory, and less than 100 MB local disk for logs and buffering on supported hosts.
Metric historyHealth metric history follows the workspace monitoring-data retention policy.

Threshold Baseline

Launch Health thresholds use whole percentage values for the percentage metrics collected by the agent. Disk read and write byte-throughput metrics are available for analysis, but they do not have default launch thresholds.

Threshold fieldMetricDefault warningDefault critical
thresholds.cpu_utilization_percenthealth.cpu.utilization_percent80%95%
thresholds.memory_utilization_percenthealth.memory.utilization_percent85%95%
thresholds.disk_used_percenthealth.disk.used_percent85%95%
thresholds.disk_io_utilization_percenthealth.disk.io_utilization_percent80%95%

Each threshold object has warning and critical fields. Custom values must be whole percentages from 1 through 100, supplied as a pair, with critical greater than warning. Threshold state is clear, warning, critical, or unknown; stale or missing telemetry evaluates as unknown. The dashboard is the primary threshold-editing surface, with API updates and config-file seeding available for automation.

Configuration Example

Configuration note

Health Monitoring uses health-agent-config.yml for collection interval, local buffer, metric toggles, and threshold seeds. Configure ongoing CPU, memory, disk, and disk I/O utilization thresholds from the dashboard or API.

health-agent-config.yml
agent:
  collection_interval_seconds: 60
  local_buffer_hours: 24
metrics:
  cpu_usage: true
  memory_usage: true
  disk_usage: true
  disk_io: true
thresholds:
  cpu_utilization_percent:
    warning: 80
    critical: 95
  memory_utilization_percent:
    warning: 85
    critical: 95
  disk_used_percent:
    warning: 85
    critical: 95
  disk_io_utilization_percent:
    warning: 80
    critical: 95

Setup Flow

  1. Confirm the host is inside the supported Linux or Windows Server OS matrix.
  2. Confirm local administrator access for installation and outbound HTTPS access to Bitaic.
  3. Install the Health Monitoring agent on the host.
  4. Enable the required CPU, memory, disk usage, and disk I/O metrics.
  5. Configure safe threshold values in the dashboard, through the API, or by seeding launch values in health-agent-config.yml.
  6. Start the agent and confirm the dashboard shows host identity, agent status, recent metrics, and alert state.

Example Workflow: Monitor a Production Host

Goal: install Health Monitoring on a host, collect core resource metrics, and verify alerts before the host becomes a reliability risk.

  1. Choose the host to monitor and confirm it is in the supported systems matrix with the required operating-system permissions. Use macOS only as a CLI workstation for Health Monitoring workflows.
  2. Install the Health Monitoring agent with local administrator rights and authenticate it to the correct Bitaic workspace.
  3. Set the collection interval and enable CPU, memory, disk usage, and disk I/O metrics in health-agent-config.yml.
  4. Use the default percentage thresholds or tune them for the host role, then connect those thresholds to the alert route used by the operations team.
  5. Start the agent and confirm the dashboard shows fresh host identity, agent status, metrics, and alert state.
  6. During normal operations, compare resource trends with deployments, scheduled jobs, capacity changes, and application latency.
Success criteriaExpected result
Host is reportingThe dashboard shows the host with a running agent status, fresh telemetry state, and recent metric timestamps.
Core metrics are collectedCPU, memory, disk usage, and disk I/O values appear for the host.
Thresholds are actionableAlert states use clear, warning, critical, or unknown severity and map to thresholds the operations team understands for the host role.
Capacity review is possibleHistorical trends give the team enough context to investigate sustained CPU, memory, disk, or disk I/O pressure.

Data, Alerts, And Dashboard Output

OutputPurpose
CPU utilizationShows health.cpu.utilization_percent so teams can identify sustained resource pressure and noisy processes.
Memory utilizationShows health.memory.utilization_percent before applications begin swapping, degrading, or failing.
Disk usageShows health.disk.used_percent before full disks interrupt logging, databases, queues, or application writes.
Disk I/OTracks health.disk.read_bytes_per_second, health.disk.write_bytes_per_second, and health.disk.io_utilization_percent to identify storage bottlenecks that can make otherwise healthy services feel slow.
Host identityConnects metrics to the monitored server or host, including operating-system family, version, and architecture.
Agent statusConfirms whether Bitaic is receiving fresh health telemetry from the host, using health.agent.heartbeat_age_seconds for freshness.
Alert threshold stateShows whether CPU, memory, disk-used, or disk I/O utilization thresholds are clear, warning, critical, or unknown.

Bitaic alerts when CPU, memory, disk-used, or disk I/O utilization thresholds reach warning or critical. Alert routing uses the same notification and incident integrations as other Bitaic monitoring products.

Dashboard Views

  • Current host status with the latest CPU, memory, disk, disk I/O, and agent-state values, plus telemetry freshness.
  • Historical metric trends that help teams compare current resource pressure with prior behavior.
  • Threshold and alert-state views that show which metric crossed a safe limit, the configured warning and critical values, and when the alert began.

CLI And API

CLI support includes health install, start, agent status, and health status commands. API support includes retrieving health metrics and managing health thresholds.

  • Create or list monitored hosts with /v1/workspaces/{workspace_id}/targets and type: "host".
  • Attach host health checks with /v1/workspaces/{workspace_id}/targets/{target_id}/checks and type: "host_health".
  • Retrieve health metric data with /v1/workspaces/{workspace_id}/metrics and metrics such as health.cpu.utilization_percent, health.memory.utilization_percent, health.disk.used_percent, and health.agent.heartbeat_age_seconds.
  • Update health thresholds with /v1/workspaces/{workspace_id}/checks/{check_id} and the nested thresholds fields used by host_health checks.
bitaic install agent health
bitaic agent start health
bitaic agent status health
bitaic health status
$ bitaic health status
host: app-server-01
os_family: linux
os_version: ubuntu-22.04
architecture: x86_64
agent_status: running
telemetry_state: fresh
agent_freshness_seconds: 18
collection_interval_seconds: 60
cpu_usage_percent: 42
memory_usage_percent: 68
disk_usage_percent: 71
disk_read_bytes_per_second: 1048576
disk_write_bytes_per_second: 524288
disk_io_utilization_percent: 19
alert_state: clear
checked_at: 2026-08-18T14:30:00Z

Troubleshooting

SymptomLikely causeNext check
Metrics stop updatingThe Health Monitoring agent may be stopped, disconnected, or unable to send telemetry. Bitaic marks telemetry stale after three missed collection intervals.Run bitaic agent status health, confirm outbound HTTPS access to api.bitaic.com and ingest.bitaic.com, and review service-account permissions.
CPU or memory alert firesThe host exceeded its warning or critical utilization threshold, or a workload is using more resources than expected.Compare recent metric history with deployments, scheduled jobs, and application telemetry.
Disk usage alert firesAvailable disk capacity may be below the configured disk-used threshold.Check logs, temporary files, database growth, queue backlogs, and cleanup jobs on the host.
Disk I/O looks unhealthyStorage latency, queue depth, or utilization may be affecting host performance.Review disk I/O trends next to application latency and host-level workload changes.
Host is missing from the dashboardThe agent may not be installed, authenticated, started, or associated with the expected account.Verify installation, configuration, agent status, and dashboard organization or project selection.