Available on the Enterprise plan. Contact sales to learn more.
Enabling metrics collection
- Go to Settings → Runners
- Select your runner
- Toggle Enable metrics collection
- Enter your configuration:
- Click Save Configuration
What to monitor
Runners expose many metrics, but not all require your attention. Some indicate issues you can resolve directly in your cloud account. Others signal problems that require Ona support. The rest provide visibility into usage and system health.Act on these
These metrics reflect infrastructure you control. Set up alerts and respond directly.Contact support for these
These metrics indicate issues within the runner itself. You can’t resolve them directly, but they help you know when to reach out.Informational
These metrics provide visibility but don’t typically require action.Example alerts
These alerts cover high-signal scenarios that directly impact your users. Runner and proxy availability determine whether users can access environments at all. Proxy error rates indicate active failures during environment connections. These are the first things to know about when something goes wrong.Runner unreachable
Check your network configuration, security groups, and firewall rules.Proxy error rate elevated
Indicates users are experiencing failures connecting to environments.High error rate (contact support)
This alert signals an issue you can’t fix directly. Contact support with the time window and error details.Available metrics
All metrics include these common labels:
The tables below list additional metric-specific labels where applicable.
Standard
Common metrics available on all runners.Environment (gitpod_runnerkit_*)
Metrics for environment lifecycle operations including creation, supervision, and state management.
Snapshots (snapshot_*)
Metrics for environment snapshot operations used for persistence and restore.
Work queue (workqueue_*)
Internal task queue metrics. A growing workqueue_depth or high workqueue_unfinished_work_seconds may indicate the runner is falling behind on processing. Contact support if these remain elevated.
Errors (environment_error_*)
Tracks environment-level errors. Use the error_code and component labels when reporting issues to support.
Runner proxy (gitpod_gateway_proxy_*)
The runner proxy handles all traffic between users and environments. It runs as a container named proxy in the same ECS task as the runner (AWS deployments).
HTTP requests
Connections
Backend
DNS
TLS
Security
Warm pools (warm_pool_*)
Metrics for warm pool scaling, instance lifecycle, and claim performance. All metrics include a warm_pool_id label.
Key metrics to watch:
warm_pool_claims_totalwithresult="instance_not_found": Indicates users hit a cold start because no warm instance was available. If this happens frequently, increasemax-sizeormin-size(the pool may be scaling down too aggressively).warm_pool_claim_instance_age_seconds: Shows how long instances waited before being claimed. Very short ages may indicate the pool is too small for demand.warm_pool_instances_by_state: Comparein_servicevsstoppedcounts to verify the pool is scaling as expected.
AWS-specific (gitpod_ec2_runner_*, gitpod_ecs_*)
Metrics specific to AWS runner deployments. The gitpod_ecs_* series are sourced from the ECS Task Metadata Endpoint and report task- and container-level resource usage. They are emitted on every ECS launch type (EC2 and Fargate) and can be used to detect a hot or memory-pressured runner task before the symptoms surface elsewhere.
GCP-specific (gitpod_gcp_*)
Metrics specific to GCP runner deployments, tracking compute and Redis connectivity.
GCP Runner alerts and dashboards
If you are using a GCP Runner, pre-built Grafana alerts and a dashboard are available that you can import directly. See Alerts and Dashboards for details.Troubleshooting
Metrics not appearing
Metrics not appearing
High cardinality
High cardinality
- Aggregate at runner level instead of per-environment
- Adjust retention for high-volume metrics