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.

Public release

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.
Permission requirement

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

BehaviorLaunch handling
ProtocolsEndpoint 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 authChecks 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.
RedirectsRedirect 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 codesFinal 2xx and 3xx responses are available by default. Configure expected status codes when a target intentionally uses a different success response.
Cadence, timeout, and retryActive 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 statesPaused 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 behaviorLaunch handling
Field namesEndpoint 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 measurementValues 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 validationWhen 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.
OwnershipThe 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 modelCompleted 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

Configuration note

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: 30

Setup Flow

  1. Add the endpoint URL to the monitored endpoint list.
  2. Confirm the request method, redirect handling, expected status codes, check interval, and timeout for the URL.
  3. Configure response-time warning and critical thresholds in the dashboard, API, or endpoint configuration surface.
  4. Enable Certificate Monitoring for HTTPS endpoints when the same URL should also be watched for certificate expiration.
  5. Start or refresh the endpoint monitoring collection path.
  6. 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.

  1. Choose the URL that best represents the service experience customers depend on, such as a health check, API route, or web page.
  2. Add the URL to the endpoint configuration and set response-time warning and critical thresholds, plus optional Certificate Monitoring expiration thresholds for the target.
  3. Start or refresh the endpoint monitoring collection path so Bitaic can check the URL.
  4. Run a manual endpoint check or wait for scheduled collection, then confirm availability, status code, redirect count, response time, uptime state, and alert state.
  5. Route downtime and slow-response alerts to the team that owns the application or service.
  6. During normal operations, compare response-time history with deployments, incidents, and dependency changes when latency begins to rise.
Success criteriaExpected result
URL is monitoredThe endpoint appears in the dashboard with current availability and a recent check time.
Response time is usableCheck output includes response_time_ms, warning and critical threshold values, and a dashboard severity state.
Alert state is clearHealthy endpoints show an available or clear state, while downtime and slow-response states are ready to notify the owner.
Operations loop is closedThe owning team has a dashboard target, alert route, and recent history for incident review.

Data, States, Alerts, And Dashboard Output

OutputPurpose
Endpoint URLIdentifies the monitored web service or application target.
Availability stateShows whether the latest check considers the endpoint available, unavailable, degraded, paused, or unknown.
Status code and redirect resultRecords the final HTTP status code, final URL, and redirect count so teams can distinguish a healthy redirect from a loop or unexpected destination.
Response timeRecords response_time_ms, measured through final response headers after redirect handling, so teams can detect latency regressions and slow-service alerts.
Response-time thresholdsShows the configured warning and critical values used to classify slow available checks.
Check schedule and timeoutShows 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 historyProvides the historical context needed to review reliability, incident windows, and recurring availability problems.
Certificate statusAppears for HTTPS endpoints when Certificate Monitoring is enabled on the same target.
Alert threshold stateShows 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}/targets and type: "endpoint".
  • Attach availability checks with /v1/workspaces/{workspace_id}/targets/{target_id}/checks and type: "endpoint_availability".
  • Retrieve response-time data with /v1/workspaces/{workspace_id}/metrics and metric=endpoint.response_time_ms.
  • Update response-time thresholds with /v1/workspaces/{workspace_id}/checks/{check_id} and thresholds.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:00Z

Troubleshooting

SymptomLikely causeNext check
Endpoint is unavailableThe 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 unknownBitaic 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 firesThe 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 dashboardThe 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 channelAlert routing or integration configuration may be incomplete.Review the alert policy, notification integration, and threshold state for the endpoint.
Certificate alert appears on an endpointCertificate 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.