Glossary · Observability
What Is Continuous Profiling?
Written by
Amber Jain
Published
June 2026
Reading time
4 min read
Continuous profiling shows you which lines of code are burning CPU or memory in production, not in a lab.
Continuous profiling is the ongoing, low-overhead sampling of a running production application to see which functions and lines of code consume CPU, memory and other resources, often described as the fourth signal of observability alongside metrics, logs and traces.
How it works
A profiler periodically samples the call stacks of a running process, building a statistical picture of where time and memory go, down to the function and line. Doing this continuously in production, at low overhead, means you always have profiling data for the moment a problem occurred, rather than trying to reproduce it later.
Why it complements the other signals
Traces tell you which service and which call is slow; profiling tells you which code inside that service is responsible. When a service is CPU-bound or leaking memory, a trace localises it to the service and a profile localises it to the function, which is why profiling is increasingly treated as a first-class observability signal.
How it fits Opstral
As profiling matures as a signal, it feeds the same picture Telemetry Ops builds, giving Sentinel AI code-level context for CPU and memory incidents.
Frequently asked questions
Is continuous profiling high overhead?
No, modern continuous profilers sample at low overhead, which is what makes running them always-on in production practical.
How is profiling different from tracing?
Tracing shows which service and call is slow across a request; profiling shows which code inside a process consumes CPU or memory.