Monitoring Cisco IOS Running Processes with show processes

Learn how to use Cisco IOS show processes to read CPU utilization, interpret process fields and states, and investigate sustained high CPU safely.

Cisco IOS performs many tasks at the same time. Internal processes handle routing protocols, control-plane activity, management access, logging, packet processing, timers, and other device functions. The show processes command provides a view of those processes and their scheduler statistics.

Process monitoring is useful when a router or switch responds slowly, command output is delayed, control-plane behavior is sluggish, or network performance has degraded. The output can help identify which IOS task is consuming processor time. It is a direction for investigation, not always a complete root-cause diagnosis.

Prerequisites: You should understand privileged EXEC mode, basic IOS command navigation, CPU utilization, the difference between data-plane forwarding and control-plane processing, and the general use of show commands. For background, review the computer network basics and OSI reference model.

Run show processes

Enter the command from privileged EXEC mode, identified by a prompt ending in #:

Router> enable
Router# show processes

The command normally displays an overall CPU utilization summary followed by individual process entries. Exact columns, state labels, options, and formatting vary across Cisco IOS platforms and software releases.

Some releases also support a CPU-focused form:

Router# show processes cpu

Use this form only when the platform and IOS release support it. Syntax and available options differ between platforms, so use show processes ? or the platform documentation when necessary.

Read the CPU utilization summary

The summary reports CPU utilization over approximately the previous 5 seconds, 1 minute, and 5 minutes. These intervals provide short-term and longer-term context.

Observed 5-second, 1-minute, and 5-minute pattern	Likely interpretation	Suggested next step
High 5-second value with lower 1-minute and 5-minute values	Probably a recent or brief CPU spike	Check whether the condition repeats and correlate it with a recent event, traffic burst, log activity, or management operation.
High values across all intervals	Sustained processor pressure	Review process activity, then correlate the leading process with protocols, interfaces, logs, traffic, and recent changes.
Low values across all intervals despite a reported user symptom	The symptom may not be caused by current CPU exhaustion, or the load may have ended	Investigate interfaces, forwarding, errors, connectivity, control-plane symptoms, and timing of the complaint.

A high short-term value with low longer-term values is different from consistently high values. Persistent CPU usage is more likely to explain ongoing slow command response or delayed control-plane work.

On output formats that show two percentages for an interval, the first commonly represents total CPU utilization and the second represents CPU attributed to interrupt processing. Interrupt processing handles work triggered directly by hardware or packet events. Compare the interrupt value with the total value when it is present. A large interrupt component points toward investigating packet rates, interfaces, switching behavior, or other event-driven activity. The exact labels and accounting can vary by IOS version.

Understand the process table

Each process entry contains identifiers, scheduler information, CPU accounting, stack information, and a human-readable name. The process name is usually the most useful starting point, while fields such as the program counter are mainly for advanced diagnosis.

Field	Meaning	How to Use It During Troubleshooting
PID	Process ID: the numeric identifier assigned to the process.	Use it to distinguish entries and refer to a specific process in collected evidence.
Q	Process queue priority.	Shows scheduler importance; it does not prove that the process is causing high CPU.
Ty	Scheduler state or process type code, depending on the IOS format.	Interpret it with the release-specific legend and determine whether the process is running, ready, waiting, sleeping, hung, or terminated.
PC	Program counter: an internal execution-location value.	Usually useful only for advanced diagnosis or Cisco support, especially when paired with software and platform details.
Runtime	Accumulated CPU time consumed by the process.	Compare values and trends to find processes that have consumed unusually large amounts of processor time.
Invoked	Number of times the process has been scheduled or called.	High values can indicate very frequent work, but frequency alone does not establish excessive CPU use.
microSecs	Average CPU time used per invocation, in microseconds.	High values suggest expensive individual executions; evaluate them with invocation count and total runtime.
Stacks	Process stack information, often available stack space or a low-water mark.	Use it to notice possible stack-space concerns, but interpret the format according to the IOS release.
TTY	Terminal line or session associated with the process, when applicable.	Can help correlate activity with a console, VTY, or other terminal session.
Process	Human-readable name of the IOS function.	Use this as the main clue for selecting related protocol, interface, logging, packet, or management checks.

Runtime is cumulative. A large value may reflect a process that has been active for a long time rather than a problem occurring at this exact moment. If possible, collect output at two points in time and compare how quickly values change. Also remember that output formatting and field names may differ on a switch, router, or different IOS release.

Process queue priority

Process queue priority is a scheduler classification. It indicates how important a process is relative to other work when the IOS scheduler decides what should run. Priority is not a measurement of CPU consumption and does not, by itself, identify the source of a high-CPU condition.

Code	Priority Level	Interpretation
C	Critical	Highest-priority queue classification. A critical process can still be a low CPU consumer.
H	High	High scheduler queue classification.
M	Medium	Medium scheduler queue classification.
L	Low	Low scheduler queue classification.

Evaluate priority together with runtime, invocation count, microseconds per invocation, process state, and the observed device symptom. For example, a low-priority process with very large runtime may deserve more attention than a critical process with negligible runtime.

Interpret scheduler states

A scheduler state describes what a process is doing or waiting for. Waiting and sleeping are often normal: many IOS processes remain inactive until an event or timer requires work. A state should be interpreted with CPU statistics and the process name, not in isolation.

State Code	General Meaning	Troubleshooting Significance
*	Currently running	Shows the process currently using the processor when the snapshot was taken. It is not automatic evidence of a fault.
E	Event-waiting state	The process is waiting for an event or condition.
S	Sleeping or inactive	Often normal while the process waits for work.
rd	Runnable or ready after voluntarily releasing the processor	The process can run again when scheduled; this alone does not indicate a fault.
we	Runnable or ready because its wakeup condition occurred	The process has become eligible to run after waiting for an event.
sa	Sleep or wait state associated with an asynchronous condition	Usually requires context from the process and IOS version.
si	Sleep or wait state associated with an interrupt-related condition	Interpret with the platform-specific state legend.
sp	Sleep state	Often normal while awaiting work.
st	Timer-related sleep or wait	The process is waiting for a timer or interval.
hg	Hung	Significant condition: the process is not expected to execute again and needs careful documentation and investigation.
xx	Terminated but not yet deleted, also called dead	The process has ended but remains temporarily in the process table; repeated or unexpected occurrences warrant investigation.

State abbreviations can vary slightly by IOS version. A timer-related process might wait until an interval, an absolute time, or a timer expires. A process that voluntarily releases the processor and one whose wakeup condition has occurred can both be shown as ready or runnable, but their scheduler reasons differ.

A practical method for investigating high CPU

Confirm the condition. Run show processes and determine whether CPU is high over only 5 seconds or across the 1-minute and 5-minute intervals. Confirm whether the symptom is still occurring.
Review process activity. Compare process names with runtime, invocation count, and microseconds per invocation. Look for entries that are disproportionately active, rather than selecting a process from one column alone.
Identify the likely function. Use the process name to select related checks. A routing-related process suggests examining routing neighbors and updates; a packet-related process suggests checking traffic rates and interfaces; a logging or management process suggests reviewing logs and remote access.
Correlate evidence. Check recent configuration changes, traffic conditions, interface errors, routing events, logging activity, and console or VTY access. A process can be busy because another condition is generating work.
Collect before changing. Save relevant command output, software version, platform, uptime, timestamps, and related protocol or interface data. Then consult platform-specific guidance before making a change.

The process table identifies a direction for investigation. It does not always identify the root cause by itself. CPU consumption may be a consequence of traffic, a protocol event, a configuration change, repeated errors, management polling, or a software defect.

Frequent lightweight work versus expensive work

Consider two patterns:

Process A: many invocations, low microseconds per invocation
Process B: fewer invocations, high microseconds per invocation

Process A performs many small units of work. Process B performs fewer but more expensive executions. Either can contribute substantially to CPU usage. Compare both invocation count and average cost with total runtime and the time over which the values accumulated.

Example: sustained CPU and slow CLI response

If command response is slow and the CPU summary remains high over all reported intervals, treat the condition as sustained processor pressure. Find processes with unusually high runtime or activity, identify their names, and correlate them with protocol status, interface traffic and errors, logs, recent changes, and management requests. Collect additional diagnostics before changing configuration.

Example: a high invocation count

A high invocation count with a low average microseconds-per-invocation value means the process performs many small operations. Compare its total runtime with other processes and look for unusually frequent packets, protocol updates, events, or management requests related to its name.

Example: a high microseconds-per-invocation value

A high average cost means individual executions may be expensive. Determine whether the process also runs frequently, compare its total runtime, and investigate the function represented by the process name.

Example: waiting and sleeping processes

If most processes are waiting or sleeping, that can be normal. IOS processes commonly wait for events or timers. Use CPU trends and runtime metrics instead of treating waiting states alone as evidence of a performance problem.

Example: a hung process

A hung state is more serious than an ordinary waiting or sleeping state. Record the full output, software version, platform, uptime, timestamps, and related logs. Use vendor guidance or support procedures rather than attempting ad hoc process manipulation.

Safe operational interpretation

Do not attempt to stop, delete, reprioritize, or otherwise alter an internal IOS process solely because it appears in the output or has a high priority. Internal processes are part of device operation, and an inappropriate intervention can worsen the outage.

Collect relevant show command output first. Depending on the process name and symptom, include protocol status, interface counters and errors, logging information, management-session details, traffic observations, software version, and uptime. For routing-related symptoms, protocol checks such as OSPF configuration and status review may be relevant. For time-related event correlation, review NTP configuration.

Escalate to platform documentation or Cisco support when a process remains hung, CPU usage is unexplained and sustained, the device is unstable, or the output suggests a platform-specific software issue. Include timestamps and unmodified command output in the escalation record.

Exam-relevant notes

show processes is a privileged EXEC command that displays active IOS processes and scheduler-related statistics.
CPU values over 5 seconds, 1 minute, and 5 minutes help distinguish a brief spike from sustained load.
PID is the numeric process identifier; the process-name column is the principal human-readable clue.
Priority indicates scheduler importance, not CPU consumption.
Runtime, invocation count, and microseconds per invocation must be evaluated together.
Running, ready, waiting, and sleeping states are not automatically faults.
A hung process requires careful documentation and platform-specific investigation.
Exact output and available command options vary by IOS platform and software release.