Skip to main content

Observability

This page covers unit consumption tracking, metrics endpoints, fleet health queries, dashboard limitations, and client-side monitoring recommendations for private fleets.

GraphQL Unit Consumption Tracking​

For reliable unit consumption data, use the exportMetrics query via the Browserless account API. This is more accurate than /metrics/total because it queries aggregated billing data rather than per-worker stats. It also survives Relaunches, unlike per-worker REST stats.

For the full authentication flow (login, loginSecondFactor) and the exportMetrics query, see GraphQL API.

REST Metrics API​

The /metrics and /metrics/total endpoints return session statistics for your fleet. These are useful for operational monitoring but less reliable than exportMetrics for billing data: stats are per-worker and reset after a Relaunch.

important

Private fleet customers must call these endpoints on their dedicated fleet URL, not on a shared fleet URL. Use chrome.browserless.io (or your regional variant), not production-sfo.browserless.io.

# Get per-interval metrics (last ~7 days, in 5-minute buckets)
curl "https://chrome.browserless.io/metrics?token=YOUR_TOKEN"

# Get aggregate totals
curl "https://chrome.browserless.io/metrics/total?token=YOUR_TOKEN"

Calling /metrics does not consume units.

See Metrics API for the full response schema and examples.

note

Do not include a Content-Type: application/json header on GET requests to the metrics REST endpoint. This returns HTTP 400. GET requests do not require a content type header.

Known limitations​

  • Metrics reset after a Relaunch. New VMs have no history. estimatedMonthlyUnits is unreliable for several hours until sufficient data accumulates.
  • Request counts can appear inflated. When a health-rejected request is forwarded to another worker in the fleet, both the rejection and the forwarded request may be counted separately. Compare against your client-side request counts if you see unexpected discrepancies.

GraphQL API for Fleet Health​

The Browserless GraphQL API provides real-time visibility into fleet health and session activity. Use your dedicated fleet API token for all queries.

  • pressure(): current load and availability. Useful for pre-session checks before connecting.
  • metrics(): per-interval CPU, memory, and session success/failure counts.
  • sessions(): currently running browser sessions.
  • exportMetrics(): aggregated unit consumption data by time slot. More reliable than REST metrics for billing purposes.

See GraphQL API for query examples and the full schema.

Dashboard Limitations​

The dashboard provides a useful operational view, but has limitations:

  • Health-check rejections (HTTP 500 when CPU/memory exceeds 90%) do not appear in dashboard session counts. Because the request is rejected before a browser is created, no session is ever logged.
  • Browser-side errors (JavaScript exceptions thrown on your target page) are not recorded by Browserless. Implement your own error logging within browser sessions if you need this visibility.
  • Server-side container logs are not accessible to customers. Contact Browserless support for server-side log investigation.

Client-Side Monitoring​

Because dashboard metrics have limitations and may not reflect gradual performance degradation, instrument your own client-side timing. Track the following for each session:

  • WebSocket connection time (time to establish the browser connection)
  • Page navigation time (page.goto() duration)
  • Total session duration

Alert on upward trends over days, not only on absolute error thresholds. A gradual increase in session times over one to two weeks is the typical early indicator that a Relaunch would restore performance.