Product Guides
Runtime
Use Runtime to inspect service pressure signals such as CPU, memory, allocation, garbage collection, event loop, thread activity, and exceptions when available.
Overview
Use Runtime to decide whether the service process itself is under pressure. It helps explain broad latency, error bursts, memory pressure, allocation changes, exception bursts, and runtime-specific saturation.
Use this page after you know the approximate symptom and need to decide which evidence should come next. Keep the service, environment, and time range consistent as you move from summary pages to request-level detail.
How to read this page
Choose a service before comparing runtime charts. Read runtime signals as supporting evidence alongside traces and logs. Compare the same time range used in the original service or trace investigation.
- Pressure timing
- Runtime charts are most useful when pressure starts near latency or error changes.
- Signal shape
- Sustained pressure is stronger evidence than a single short spike.
- Cross-check
- Traces and logs should confirm whether pressure affected real requests.
Investigation workflow
Use this sequence when you need to move from a broad symptom to evidence you can share with another teammate.
- 1
Open Runtime for the affected service and incident window.
- 2
Compare memory, CPU, allocation, event loop, thread activity, or exception signals with the symptom.
- 3
Open traces and logs from the same window to confirm user-facing impact.
Interpretation note
Do not blame runtime pressure if traces point to one slow dependency. Do not compare runtime charts across services with different traffic profiles. Do not ignore missing runtime metrics. Fix setup or use traces and logs as fallback evidence.