Skip to main content
Available on the Enterprise plan. Contact sales to learn more.
Want to send metrics to your own observability stack? See Custom metrics pipeline.
Ona managed metrics lets you opt in to having Ona monitor your runner’s operational health. When enabled, the runner pushes a curated set of Prometheus metrics to the Ona management plane, where the Ona team uses them to detect degradation and catch problems before they affect your developers. This is independent of the custom metrics pipeline, where you configure your own Prometheus remote write endpoint. Both can run simultaneously — managed metrics go to Ona, self-managed metrics go to your own observability stack.

​
Why enable managed metrics

Without metrics visibility, Ona cannot detect runner issues until you report them. Managed metrics close this gap:
  • Proactive monitoring — Ona detects degraded runners, resource exhaustion, and elevated error rates before developers are impacted.
  • Faster incident resolution — When you contact support, the Ona team already has the operational context they need.
  • Zero setup on your side — No Prometheus endpoint to configure, no dashboards to build. Toggle it on and the runner handles the rest.
  • Non-sensitive data only — The curated metric set contains only operational counters, gauges, and histograms. No user data, source code, or secrets are ever sent.

​
Enabling managed metrics

  1. Go to Settings → Runners
  2. Select your runner
  3. Toggle Ona managed metrics
The setting saves immediately — no additional confirmation is needed. Runner settings showing the Ona managed metrics toggle Metrics begin flowing within 60 seconds. No additional network configuration is required — the runner pushes metrics to the management plane over the same connection it already uses.

​
What metrics are reported

The curated metric set answers: “Is this runner healthy and performing well?” Metrics are filtered to a hardcoded allowlist in the runner binary. Adding or removing metrics requires a runner release, which provides a natural review gate.

​
Environment lifecycle

MetricTypeDescription
gitpod_runnerkit_active_instancesGaugeCurrent environment count by state
gitpod_runnerkit_environment_operation_duration_secondsHistogramDuration of environment operations
gitpod_runnerkit_function_calls_totalCounterTotal function calls by function name
gitpod_runnerkit_function_errors_totalCounterTotal function errors by function name

​
Supervisor connectivity

MetricTypeDescription
gitpod_runnerkit_supervisor_status_events_totalCounterSupervisor status events received
gitpod_runnerkit_supervisor_watch_closes_totalCounterSupervisor watch connection closes by reason

​
Inverted RPC

These metrics track request delivery from the management plane to the runner over the runner’s WatchRequests stream.
MetricTypeDescription
gitpod_runnerkit_inverted_rpc_requests_received_totalCounterInverted RPC requests and events received by request type
gitpod_runnerkit_inverted_rpc_async_queue_depthGaugeCurrent number of queued or running asynchronous inverted RPC requests
gitpod_runnerkit_inverted_rpc_async_queue_capacityGaugeConfigured asynchronous inverted RPC queue capacity
gitpod_runnerkit_inverted_rpc_async_queue_enqueues_totalCounterAsynchronous inverted RPC enqueue attempts by request type and outcome
gitpod_runnerkit_inverted_rpc_async_queue_wait_duration_secondsHistogramTime asynchronous inverted RPC requests spend waiting before handler execution starts
gitpod_runnerkit_inverted_rpc_handler_duration_secondsHistogramRunner-side inverted RPC handler duration by request type and result code
gitpod_runnerkit_inverted_rpc_send_responses_totalCounterAttempts to send inverted RPC responses back to the management plane
gitpod_runnerkit_inverted_rpc_watch_stream_connects_totalCounterWatchRequests stream connection attempts by delivery path and outcome
gitpod_runnerkit_inverted_rpc_watch_stream_duration_secondsHistogramWatchRequests stream session duration by delivery path and close reason

​
Snapshots and warm pools

MetricTypeDescription
snapshot_reconcile_duration_secondsHistogramSnapshot processing time by phase
snapshot_in_progressGaugeActive snapshot operations
snapshot_timeouts_totalCounterSnapshot timeouts
warm_pool_reconcile_duration_secondsHistogramWarm pool reconciliation duration
warm_pool_deletions_totalCounterWarm pool instance deletions

​
Work queue health

MetricTypeDescription
workqueue_depthGaugeCurrent queue depth
workqueue_queue_duration_secondsHistogramTime items spend waiting in queue
workqueue_work_duration_secondsHistogramTime spent processing items
workqueue_retries_totalCounterProcessing retries

​
LLM proxy health

Scoped to proxy health only. No token counts, no prompts, no usage patterns. Ona can see whether the proxy is succeeding and how fast it responds — nothing about what you send through it.
MetricTypeDescription
gitpod_llm_proxy_requests_completed_totalCounterFinal request outcome (success, exhausted, rejected) per endpoint and model
gitpod_llm_requests_duration_secondsHistogramEnd-to-end proxy request latency
gitpod_llm_errors_totalCounterProvider-side errors returned inside 200 responses, by error type
gitpod_llm_failover_totalCounterFailovers between configured LLM providers
Token usage metrics (gitpod_llm_input_tokens_total, gitpod_llm_output_tokens_total, cache counters, etc.) are deliberately excluded from the allowlist. They remain available to your own custom metrics pipeline if you want them, but they are never forwarded to Ona.

​
Agent and MCP

MetricTypeDescription
gitpod_mcp_*VariousMCP proxy request duration and count
gitpod_memory_*VariousRedis memory usage, eviction cycles, and conversation age
gitpod_skill_*VariousSkill API discovery metrics

​
Runner operations

MetricTypeDescription
gitpod_runner_manager_*VariousRunner manager operational metrics
gitpod_runner_scm_*VariousSCM token refresh, cache invalidation, and TTL
gitpod_runner_updater_*VariousRunner self-update duration and count
gitpod_ip_allocator_*VariousIP address allocation metrics
gitpod_kvstore_*VariousKey-value store operation metrics

​
Process health

MetricTypeDescription
go_goroutinesGaugeCurrent goroutine count
go_memstats_alloc_bytesGaugeAllocated heap memory
process_cpu_seconds_totalCounterTotal CPU time consumed

​
Cloud-specific metrics

MetricTypeDescription
gitpod_ec2_runner_*VariousEC2 runner operational metrics
gitpod_ecs_task_*Gauge / CounterTask-level CPU, memory, and network usage from the ECS Task Metadata Endpoint
gitpod_ecs_container_*Gauge / CounterPer-container CPU, memory, and network usage within the runner task
environment_error_errors_totalCounterEnvironment errors by code and component

​
How it works

  1. The runner’s Prometheus registry collects metrics every 15 seconds (this already happens for normal runner operation).
  2. A managed metrics reporter filters the registry to the curated allowlist, encodes the result as a Prometheus remote write payload, and compresses it with Snappy.
  3. The runner pushes the compressed payload to the Ona management plane every 60 seconds over the existing authenticated connection.
  4. The management plane validates the payload, adds identifying labels (organization_id, runner_id, runner_region, runner_type), and forwards it to Ona’s internal monitoring infrastructure.
Typical payloads are 5–15 KB compressed. The reporter runs independently of any self-managed metrics endpoint you may have configured.

​
Auditing reported metrics

Every metrics payload the runner sends to Ona is also written to your cloud storage bucket, so you can audit exactly what data leaves your network. Audit payloads are stored as Snappy-compressed Prometheus remote write protobufs at: 
metrics/runner/{runner-id}/{YYYY}/{MM}/{DD}/{HHmmss}.pb.snappy

​
Finding the bucket name

The bucket name is shown on your runner’s settings page. When Ona managed metrics is enabled, the bucket URI appears below the toggle. Click the copy icon to copy it. Runner settings showing the metrics audit bucket URI with a copy button

​
Listing and downloading audit payloads

aws s3 ls s3://YOUR_LOGS_BUCKET/metrics/runner/YOUR_RUNNER_ID/ --recursive

# Download a specific payload
aws s3 cp s3://YOUR_LOGS_BUCKET/metrics/runner/YOUR_RUNNER_ID/2026/04/10/143000.pb.snappy ./payload.pb.snappy

​
Decoding audit payloads

Each .pb.snappy file is a Snappy-compressed Prometheus remote write WriteRequest protobuf. You can decode it with standard Prometheus tooling or any protobuf decoder: 
# Using protoc (requires prometheus remote write proto definition)
cat payload.pb.snappy | python3 -c "
import sys, snappy
sys.stdout.buffer.write(snappy.decompress(sys.stdin.buffer.read()))
" | protoc --decode=prometheus.WriteRequest remote.proto
The decoded output shows every metric name, label set, and sample value — the exact data that was sent to Ona.

​
Privacy and data handling

  • Opt-in only. Disabled by default. You explicitly enable it per runner.
  • Push-based. The runner pushes metrics to Ona. Ona never reaches into your runner or network.
  • Non-sensitive. Only operational counters, gauges, and histograms. No user data, source code, environment variables, or secrets.
  • Non-interfering. Independent of any self-managed metrics endpoint. Both can run simultaneously.
  • Auditable. Every payload is persisted to your cloud storage for inspection.
  • Transparent. The metric allowlist is hardcoded in the runner binary. Changes require a runner release and are documented on this page.