Use metrics to identify changes in resource consumption and application traffic. Bex's dashboard and API expose time series from configured telemetry backends. Metric availability varies by workload and backend; missing data is not the same as zero usage or a healthy service.
Choose a signal
| Signal | What to investigate |
|---|---|
| CPU and memory | Resource pressure, sustained growth, and capacity headroom. |
| Instance count | Scaling or availability changes alongside resource usage. |
| HTTP requests and latency | Traffic changes and slow responses for serving workloads. |
| Bandwidth | Changes in response traffic and transfer volume. |
| Datastore disk/capacity and connections | Storage pressure and excessive client connections. |
| Replication lag | Whether a supported database replica is falling behind. |
| Key Value memory and connections | Cache/queue pressure and client load. |
A worker has no public request stream, and a static site has no per-site application process. Do not assume every metric family applies to every resource.
Query a service metric
Set BEX_API_URL, an authorized BEX_TOKEN, and SERVICE_ID:
curl --fail-with-body --get "$BEX_API_URL/v1/metrics/cpu" \
-H "Authorization: Bearer $BEX_TOKEN" \
--data-urlencode "resource=$SERVICE_ID"Other service endpoints include /v1/metrics/memory, /instance-count,
/http-requests, /http-latency, and /bandwidth under the same metrics prefix.
Use startTime and endTime as RFC 3339 timestamps and resolutionSeconds
for the sampling resolution when you need a specific incident window.
The response contains time series; inspect labels and timestamps before
aggregating across instances or comparing periods.
Latency queries accept quantile, for example quantile=0.95. A percentile
is not an average: use it to observe the slower tail of requests. Keep the
same time window and resolution when comparing a deployment with its predecessor.
Datastore metrics have separate endpoints and resource-kind validation. Use the database's or Key Value store's metrics panel to choose the applicable signal rather than passing a datastore id to an application-only endpoint.
These endpoints return telemetry time series, not billing meters. For the metered totals behind an invoice — with coverage states and an advisory estimate — see Month-to-date usage.
Interpret charts with context
Correlate resource changes with deployments, request volume, instance count, and logs. A memory increase after each request can indicate a leak; a flat high-memory cache can be intentional. Higher CPU during a build is different from sustained runtime saturation. A lower request rate may mean less demand or a failure before requests reach the application.
Before scaling, check whether the bottleneck is the application, its database, an external dependency, or cluster capacity. More replicas also increase connections and other shared load.
If a chart is empty or unavailable
Check resource type, time bounds, resolution, and whether the resource ran during that interval. Verify backend collection and retention on a self-hosted instance. Bex reports unavailable telemetry when required sources are missing; do not replace that state with zeros in monitoring code.
Instance query-window and fan-out limits can reject overly broad requests. Narrow the window or resource set and use a suitable resolution. See Health checks for readiness/restart behavior and Notifications for deployment and lifecycle alerts.