Endpoint Monitoring
Endpoint Monitoring tracks configured HTTP and HTTPS URLs for availability, uptime, response time, and alert state so operations teams can identify down or slow services before customers report an outage.
Endpoint Monitoring releases publicly on Monday, October 19, 2026. Uptime Monitoring remains an availability-focused alias for this same product.
Endpoint And Uptime Naming
Bitaic uses Endpoint Monitoring as the product name in docs, navigation, search, API examples, and CLI examples. Uptime Monitoring remains a user-facing alias for availability-focused workflows and maps to this same product page.
When To Use It
- Use Endpoint Monitoring when a specific URL, application endpoint, or web service must remain available and responsive.
- Use Certificate Monitoring when the risk is SSL/TLS certificate status or certificate expiration for an HTTPS endpoint.
- Use DNS Monitoring and Domain Monitoring when the risk is resolution, nameserver behavior, registrar state, or domain expiration.
- Health Monitoring is private beta only until its Q1 2027 public release.
Prerequisites
- A Bitaic account with permission to configure monitored targets and alert thresholds.
- One or more HTTP or HTTPS endpoint URLs that product, operations, or support teams consider critical.
- Expected availability behavior for each URL, including whether a slow response should become an alert.
- Notification routing for downtime, slow response time, and optional SSL expiration alerts.
Use a Bitaic role that can manage monitored targets, alert policies, and notification routing before adding or changing Endpoint Monitoring checks.
What Bitaic Checks
- Endpoint URL and latest availability state.
- HTTP method, final status code, redirect count, and final URL.
- Uptime and downtime history for the monitored target.
- Response time for each endpoint check in whole milliseconds.
- Slow or unavailable service conditions.
- Certificate Monitoring status when certificate checks are enabled for the same HTTPS target.
- Response-time warning and critical thresholds for the endpoint.
Check Behavior
| Behavior | Launch handling |
|---|---|
| Protocols | Endpoint Monitoring supports HTTP and HTTPS URL checks at launch. TCP, UDP, ICMP, gRPC, database-native checks, and synthetic browser transactions are deferred. |
| Request method and auth | Checks use GET by default and may use HEAD when configured. Launch checks are unauthenticated and do not perform browser login, OAuth, session-cookie, mutual TLS, basic-auth, or bearer-token checks. |
| Redirects | Redirect following is enabled by default up to five hops. Bitaic records the final URL and redirect count; redirect loops or exhausted redirects count as unavailable. |
| Status codes | Final 2xx and 3xx responses are available by default. Configure expected status codes when a target intentionally uses a different success response. |
| Cadence, timeout, and retry | Active checks run every 60 seconds by default. Each attempt has a 10-second total timeout, and Bitaic retries transient DNS, connection, TLS, timeout, 429, or 5xx failures once before recording the result. |
| Paused and unknown states | Paused checks do not run or open new alerts. Unknown means Bitaic cannot trust the latest result, such as before the first result, after stale collector data, or when collection fails before the endpoint can be evaluated. |
Response-Time Thresholds
| Threshold behavior | Launch handling |
|---|---|
| Field names | Endpoint availability checks use thresholds.response_time_ms.warning and thresholds.response_time_ms.critical. CLI check output mirrors those values as response_time_warning_ms and response_time_critical_ms. |
| Units and measurement | Values are whole milliseconds. response_time_ms measures from request start through final response headers after redirect handling, including DNS, connection, TLS, redirects, and server wait time. |
| Defaults and validation | When omitted, the default warning threshold is 1000 ms and the default critical threshold is 3000 ms. Custom thresholds must be supplied together as positive integers; critical must be greater than warning and no higher than the check timeout. |
| Ownership | The dashboard is the primary editing surface. API updates use /v1/workspaces/{workspace_id}/checks/{check_id} against the same check object, and endpoint-agent-config.yml can seed thresholds for agent-managed targets. |
| Severity model | Completed available checks are clear when response_time_ms is at or below warning, warning when it is greater than warning and at or below critical, and critical when it is greater than critical. Availability failures use the endpoint availability state; unknown is reserved for untrusted latest results. |
Configuration Example
Endpoint Monitoring uses an endpoint agent configuration with a list of monitored URLs. HTTP and HTTPS checks use a 60-second default cadence, a 10-second timeout, redirect following, and default success handling for final 2xx or 3xx responses. Configure slow-response thresholds with thresholds.response_time_ms.warning and thresholds.response_time_ms.critical; use Certificate Monitoring for certificate expiration thresholds on the same HTTPS target. The ssl_alert_days value belongs to the linked certificate check, defaults to 30 days when omitted, and accepts 1 through 365 whole days when set.
endpoint-agent-config.yml
endpoints:
- url: https://your-domain.com
method: GET
follow_redirects: true
max_redirects: 5
expected_status_codes:
- 200-399
check_interval_seconds: 60
timeout_ms: 10000
thresholds:
response_time_ms:
warning: 1000
critical: 3000
ssl_alert_days: 30Setup Flow
- Add the endpoint URL to the monitored endpoint list.
- Confirm the request method, redirect handling, expected status codes, check interval, and timeout for the URL.
- Configure response-time warning and critical thresholds in the dashboard, API, or endpoint configuration surface.
- Enable Certificate Monitoring for HTTPS endpoints when the same URL should also be watched for certificate expiration.
- Start or refresh the endpoint monitoring collection path.
- Confirm that the dashboard shows availability state, response time, uptime or downtime history, and alert state for the URL.
Example Workflow: Monitor a Customer-Facing Endpoint
Goal: add a critical URL to Endpoint Monitoring, verify the first availability check, and make response-time alerts operationally useful.
- Choose the URL that best represents the service experience customers depend on, such as a health check, API route, or web page.
- Add the URL to the endpoint configuration and set response-time warning and critical thresholds, plus optional Certificate Monitoring expiration thresholds for the target.
- Start or refresh the endpoint monitoring collection path so Bitaic can check the URL.
- Run a manual endpoint check or wait for scheduled collection, then confirm availability, status code, redirect count, response time, uptime state, and alert state.
- Route downtime and slow-response alerts to the team that owns the application or service.
- During normal operations, compare response-time history with deployments, incidents, and dependency changes when latency begins to rise.
| Success criteria | Expected result |
|---|---|
| URL is monitored | The endpoint appears in the dashboard with current availability and a recent check time. |
| Response time is usable | Check output includes response_time_ms, warning and critical threshold values, and a dashboard severity state. |
| Alert state is clear | Healthy endpoints show an available or clear state, while downtime and slow-response states are ready to notify the owner. |
| Operations loop is closed | The owning team has a dashboard target, alert route, and recent history for incident review. |
Data, States, Alerts, And Dashboard Output
| Output | Purpose |
|---|---|
| Endpoint URL | Identifies the monitored web service or application target. |
| Availability state | Shows whether the latest check considers the endpoint available, unavailable, degraded, paused, or unknown. |
| Status code and redirect result | Records the final HTTP status code, final URL, and redirect count so teams can distinguish a healthy redirect from a loop or unexpected destination. |
| Response time | Records response_time_ms, measured through final response headers after redirect handling, so teams can detect latency regressions and slow-service alerts. |
| Response-time thresholds | Shows the configured warning and critical values used to classify slow available checks. |
| Check schedule and timeout | Shows whether the endpoint is actively checked, paused, or unknown and whether the latest result used the default 60-second cadence and 10-second timeout. |
| Uptime and downtime history | Provides the historical context needed to review reliability, incident windows, and recurring availability problems. |
| Certificate status | Appears for HTTPS endpoints when Certificate Monitoring is enabled on the same target. |
| Alert threshold state | Shows whether downtime, slow response time, or linked SSL Monitoring expiration rules are clear, warning, critical, or unknown. |
Bitaic alerts when an endpoint is unavailable, when response time crosses the configured slow-response threshold, or when Certificate Monitoring reports expiration risk for the same HTTPS target.
CLI And API
CLI support includes endpoint install, start, status, and check commands. API support includes retrieving endpoint metrics, managing monitored endpoints, and configuring response-time thresholds.
- Create or list monitored endpoints with
/v1/workspaces/{workspace_id}/targetsandtype: "endpoint". - Attach availability checks with
/v1/workspaces/{workspace_id}/targets/{target_id}/checksandtype: "endpoint_availability". - Retrieve response-time data with
/v1/workspaces/{workspace_id}/metricsandmetric=endpoint.response_time_ms. - Update response-time thresholds with
/v1/workspaces/{workspace_id}/checks/{check_id}andthresholds.response_time_ms.
bitaic install agent endpoint
bitaic agent start endpoint
bitaic agent status endpoint
bitaic endpoint check <url>$ bitaic endpoint check https://your-domain.com
url: https://your-domain.com
final_url: https://your-domain.com
method: GET
check_state: active
status_code: 200
availability: up
response_time_ms: 248
response_time_warning_ms: 1000
response_time_critical_ms: 3000
redirect_count: 0
uptime_state: available
alert_state: clear
checked_at: 2026-08-18T14:30:00ZTroubleshooting
| Symptom | Likely cause | Next check |
|---|---|---|
| Endpoint is unavailable | The service may be down, blocked from the collector, or returning an unexpected failure response after redirect and status-code handling. | Check the endpoint from the same network path, then review recent uptime history, final status code, redirect count, and collection status. |
| Endpoint state is unknown | Bitaic may not have a trustworthy latest result because the check has not run, collector data is stale, or collection failed before the endpoint could be evaluated. | Confirm the check is not paused, refresh collection, and review endpoint agent status before comparing service behavior. |
| Response time alert fires | The endpoint exceeded its configured slow-response threshold. | Compare recent response-time history with application, hosting, dependency telemetry, and the configured warning and critical thresholds. |
| Endpoint is missing from the dashboard | The URL may not be saved in the monitored endpoint list or the collection path has not picked up the latest configuration. | Review endpoint-agent-config.yml, restart or refresh collection, and confirm the dashboard target list updates. |
| Alert does not reach the expected channel | Alert routing or integration configuration may be incomplete. | Review the alert policy, notification integration, and threshold state for the endpoint. |
| Certificate alert appears on an endpoint | Certificate Monitoring may be enabled for the HTTPS target and the certificate is inside the configured renewal window. | Review the Certificate Monitoring page and confirm the configured ssl_alert_days value or 30-day default. |