> ## Documentation Index
> Fetch the complete documentation index at: https://hexelstudio.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Metrics
> Track latency, throughput, and resource usage of your workloads.
Metrics quantify how your workloads behave: latency, throughput, and resource consumption. They guide scaling decisions and surface problems before they become outages.
## What you can measure
| Metric area | Definition | Reported as |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- |
| **Latency** | Time from when the platform receives a request to when it sends the response. Includes agent processing time. | Percentiles: p50, p95, p99 |
| **Throughput** | Number of requests completed per second by the resource. Reflects actual work done, not just requests received. | req/sec |
| **Resource usage** | Actual CPU and memory consumption measured against the tier ceiling (e.g., 0.4 vCPU used of 0.5 vCPU `standard` tier). | Absolute value + percentage of tier capacity |
## Access
Metrics are available in the Console by resource and time range. Use them together with [usage](/docs/billing/usage) to relate performance to cost.
## Production monitoring
For production workloads, watch these signals and alert on sustained regressions:
| Signal | Watch for | Action |
| ----------------- | -------------------------------- | ---------------------------------------------------------- |
| Latency (p95/p99) | Rising tail latency | Scale out, or move to a larger tier. |
| Throughput | Sustained drop with steady input | Check instance health and provider rate limits. |
| Resource usage | CPU/memory near tier ceiling | Move to a larger [tier](/docs/compute/scaling) or add replicas. |
| Instance state | Transitions to `failed` | Inspect [logs](/docs/observability/logs) and redeploy. |
Pair metric alerts with [logs](/docs/observability/logs) so an alert links directly to the activity that caused it.
## Interpreting alerts
Three production patterns and what they indicate:
| Pattern | What you see | What it means | Action |
| ------------------------------------------------------ | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| **Latency spike + flat throughput** | p95/p99 jumps but req/sec stays constant | A downstream dependency (tool call, Data Platform query) is slow. The agent is waiting, not overloaded. | Check tool execution times and Data Platform response latency. |
| **Resource usage at ceiling + rising latency** | CPU or memory ≥ 90% of tier capacity, latency climbing | The instance is compute-bound. Requests queue because there is no headroom. | Scale to a larger tier or add replicas. This will not self-resolve. |
| **Throughput drops to zero + instance state `failed`** | No requests processed, instance transitions to `failed` | The instance crashed or failed health checks. The platform stopped routing traffic. | Inspect [logs](/docs/observability/logs) for the crash cause. Redeploy after fixing the image. |
Rate limit responses (`429`) include `X-RateLimit-Limit`, `X-RateLimit-Remaining`, and `X-RateLimit-Reset` headers. Monitor `Remaining` to anticipate throttling before it impacts users.
## Common mistakes
* **Scaling on a single spike.** Look at sustained trends, not one-off peaks.
* **Ignoring resource usage.** High CPU against tier capacity signals a need to scale or change tier.
## Best practices
* Watch latency and resource usage before and after changes.
* Use metrics to choose between scaling and moving to a larger tier.
* Set expectations based on trends, not isolated samples.
## Related pages
Qualitative detail behind the numbers.
Act on what metrics show.
Relate performance to cost.
Capacity per tier.