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.
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.
| System | Health Monitoring support | Architectures |
|---|---|---|
| Linux servers | Ubuntu 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 Server | Windows Server 2019 and Windows Server 2022. | x64 |
| macOS | macOS 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.
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_secondandhealth.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 area | Launch behavior |
|---|---|
| Local privileges | Installation 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 identity | The 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 egress | Runtime 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 buffer | Core 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 states | Telemetry 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 guardrails | Default 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 history | Health 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 field | Metric | Default warning | Default critical |
|---|---|---|---|
thresholds.cpu_utilization_percent | health.cpu.utilization_percent | 80% | 95% |
thresholds.memory_utilization_percent | health.memory.utilization_percent | 85% | 95% |
thresholds.disk_used_percent | health.disk.used_percent | 85% | 95% |
thresholds.disk_io_utilization_percent | health.disk.io_utilization_percent | 80% | 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
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: 95Setup Flow
- Confirm the host is inside the supported Linux or Windows Server OS matrix.
- Confirm local administrator access for installation and outbound HTTPS access to Bitaic.
- Install the Health Monitoring agent on the host.
- Enable the required CPU, memory, disk usage, and disk I/O metrics.
- Configure safe threshold values in the dashboard, through the API, or by seeding launch values in
health-agent-config.yml. - 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.
- 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.
- Install the Health Monitoring agent with local administrator rights and authenticate it to the correct Bitaic workspace.
- Set the collection interval and enable CPU, memory, disk usage, and disk I/O metrics in
health-agent-config.yml. - 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.
- Start the agent and confirm the dashboard shows fresh host identity, agent status, metrics, and alert state.
- During normal operations, compare resource trends with deployments, scheduled jobs, capacity changes, and application latency.
| Success criteria | Expected result |
|---|---|
| Host is reporting | The dashboard shows the host with a running agent status, fresh telemetry state, and recent metric timestamps. |
| Core metrics are collected | CPU, memory, disk usage, and disk I/O values appear for the host. |
| Thresholds are actionable | Alert states use clear, warning, critical, or unknown severity and map to thresholds the operations team understands for the host role. |
| Capacity review is possible | Historical trends give the team enough context to investigate sustained CPU, memory, disk, or disk I/O pressure. |
Data, Alerts, And Dashboard Output
| Output | Purpose |
|---|---|
| CPU utilization | Shows health.cpu.utilization_percent so teams can identify sustained resource pressure and noisy processes. |
| Memory utilization | Shows health.memory.utilization_percent before applications begin swapping, degrading, or failing. |
| Disk usage | Shows health.disk.used_percent before full disks interrupt logging, databases, queues, or application writes. |
| Disk I/O | Tracks 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 identity | Connects metrics to the monitored server or host, including operating-system family, version, and architecture. |
| Agent status | Confirms whether Bitaic is receiving fresh health telemetry from the host, using health.agent.heartbeat_age_seconds for freshness. |
| Alert threshold state | Shows 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}/targetsandtype: "host". - Attach host health checks with
/v1/workspaces/{workspace_id}/targets/{target_id}/checksandtype: "host_health". - Retrieve health metric data with
/v1/workspaces/{workspace_id}/metricsand metrics such ashealth.cpu.utilization_percent,health.memory.utilization_percent,health.disk.used_percent, andhealth.agent.heartbeat_age_seconds. - Update health thresholds with
/v1/workspaces/{workspace_id}/checks/{check_id}and the nestedthresholdsfields used byhost_healthchecks.
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:00ZTroubleshooting
| Symptom | Likely cause | Next check |
|---|---|---|
| Metrics stop updating | The 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 fires | The 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 fires | Available 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 unhealthy | Storage 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 dashboard | The agent may not be installed, authenticated, started, or associated with the expected account. | Verify installation, configuration, agent status, and dashboard organization or project selection. |