CPU utilization is really only a crude measurement of the overall resiliency of a real-time system. Therefore, the answer to your question is that it is generally a long-term average value.
The real criterion is whether all of the software tasks meet their completion deadlines. Note that this includes both tasks triggered by interrupts and tasks triggered by other kinds of events. When CPU utilization begins to approach 100%, then the completion time of lower-priority tasks tends to become arbitrarily large.
Using GPIO pins to indicate the run time of individual tasks is one good way to check whether those deadlines are ever exceeded.
Another approach is to instrument the code itself. If you have access to a free-running counter (a spare hardware counter/timer module, perhaps), then you can take a snapshot of its value at the beginning of each task, and then at the end of the task, take another snapshot and compute the difference. If this ever exceeds the required value for that task, indicate an error.
A slightly different question would be to compute the expected CPU utilization of a system, before it is implemented.
In this case, you consider each task individually, coming up with estimates of how long it runs when triggered and how often it is triggered. The run time divided by the trigger period gives the CPU utilization for that task by itself.
If you add up all of the individual utilization values and get a value that approaches or exceeds 100%, then you need to think about ways to redistribute the work — faster CPU, more CPUs, dedicated hardware for some tasks, etc.