CPU percentage vs SQL instance CPU percent: The Portal’s Favorite Misunderstanding

If you’ve ever stared at Azure SQL Database metrics and thought:
“Hold on… SQL Instance CPU Percent includes user + system, so it must be higher than CPU Percentage, right? If it’s lower… something’s broken!”
…congratulations - you’ve joined a very large and very confused club. 

I recently had a customer hit exactly this situation: cpu_percent spiking to 100% while sql_instance_cpu_percent looked chill.
The customer’s conclusion was:
“The instance metric is lower, so Azure must be lying.”
Azure was not lying. The metrics were simply… doing math on different report cards.

As per Microsoft official documentations:

Metric: cpu_percent
“How hard is your database working?”
This metric shows CPU consumption toward the user workload limit of a database or an elastic pool, expressed as a percentage.

In simpler words:

• Counts your database workload (user queries + user transactions)
• Measured against the CPU quota allocated to your database
• When it hits 100%, it means your database has used all CPU it’s allowed to use (for user workload)

Why you should care: If performance is slow and cpu_percent is high (especially near 100%), this is often the right place to look first for CPU pressure related to user workload.

100% cpu_percent = your database has exhausted all CPU allocated to it for user workload. This is the correct metric - you should care about for performance.

Metric: sql_instance_cpu_percent
“How busy is the host running SQL?”
This metric shows the total CPU consumption by the user and system workloads, expressed as a percentage. Because this metric and the CPU percentage metric are measured on different scales, they are not directly comparable with each other.

In simpler words:

• Includes your user workload
• Includes background/OS/internal SQL engine work
• Includes system activity
• Measured at the logical SQL host/instance level, not your database’s quota

Why you should care: It’s more of a platform/capacity/host health signal than a “your database is slow” signal.

The Most Common Myth: “Instance CPU includes more stuff, so it should always be higher!”

Now, the confusion is regarding – usually people interpret that since SQL Instance CPU is a combination of user + internal workload, it should always be higher than CPU percentage. But actually, that is not the case. Let me explain you with a very basic/simple example:

Think of SQL Instance CPU Percent as an apartment flat, which has multiple rooms. One of the biggest room is allocated to the CPU Percentage for just user workload and other rooms for some other internal working or background processes.

Now, suppose the user workload room is now completely filled with people with no space, therefore we can say that the room is 100 percent occupied and the metric will show you the chart is peak 100 percent.

But that does not mean that whole apartment/flat is full, therefore – since that one room is only a part of it, it will always be higher usually in metrics – until there is an issue related to background process or some internal work.

Therefore, you should focus more on the CPU percentage, if this is super high, peaking 100 percent. You should explore the Query Store during that time to identify which query is causing CPU to spike and work on it.

Note: Even on a completely idle database or elastic pool, total CPU consumption is never at zero because of background database engine activities. It can fluctuate in a wide range depending on the specific background activities, compute size, and previous user workload.

References:
Monitoring Azure SQL Database with metrics and alerts - Azure SQL Database | Microsoft Learn
Resource Management - Azure SQL Database | Microsoft Learn