How to Check Your Salesforce Flow's CPU Time in Debug Logs

In short: To check a Salesforce Flow's CPU time, open the Developer Console, set a debug log trace flag on yourself, trigger the flow, then search the log for the FLOW_START_INTERVIEWS event and the CUMULATIVE_LIMIT_USAGE section. The CPU time entry tells you how close your flow is to the 10-second synchronous limit.

If you read our post on the 5 signals that your Flow has outgrown itself, the first signal was CPU time creep. Here's how to check it in your own org. The whole process takes about 10 minutes.

Step 1: Open Developer Console and Set a Trace Flag

In Salesforce, go to Setup, search for Debug Logs, and click New under User Trace Flags. Select your own user, set the start and end time (give yourself at least 30 minutes), and set the following log levels:

• Workflow: INFO or above (this captures Flow execution events)
• Apex Code: DEBUG
• Database: INFO

Everything else can stay at the default level. Click Save.

You can also open the Developer Console directly (from the Help menu in Salesforce, then "Developer Console"), which automatically sets a trace flag for your user.

Step 2: Trigger the Flow

Do whatever action fires the flow you want to measure. If it's a record-triggered flow, create or edit the relevant record. If it's a screen flow, run through it. If it's a scheduled flow, you may need to wait for the next execution or trigger it manually in Flow Builder using the Debug button.

For the most accurate reading, trigger the flow under realistic conditions. If the flow processes related records, make sure the test record has a representative number of child records. Testing against a record with zero contacts won't tell you anything useful about a flow that loops through contacts.

Step 3: Find the CPU Time in the Log

Back in the Developer Console, open the debug log that was just generated (it appears in the Logs panel at the bottom). Use Ctrl+F (or Cmd+F) and search for CUMULATIVE_LIMIT_USAGE.

This section shows every governor limit consumed during the transaction. Look for the line that reads:

Maximum CPU time: [milliseconds used] out of [total milliseconds available]

The first number is what your transaction consumed. The second is the limit (10,000 ms for synchronous transactions, 60,000 ms for asynchronous). Divide the first number by 1,000 to get seconds.

You can also search for FLOW_START_INTERVIEWS to see exactly when Flow execution began and correlate it with the overall transaction timeline.

How to Read the Numbers

Keep in mind: these numbers represent the CPU time for the entire transaction, not just your flow. If triggers, validation rules, or other automations fire on the same object, they all share the same 10-second budget. A flow at 5,000 ms might be fine on its own, but problematic when combined with everything else in the transaction. For even more granular information about your flow, you can set the Workflow log level to FINER, run the flow, and search for the line in your log that says “FLOW_INTERVIEW_FINISHED_LIMIT_USAGE|CPU time in ms: [milliseconds used] out of [total milliseconds available].”

One More Thing: Flow Logging in Data Cloud

Salesforce introduced native Flow Logging in the Spring '26 release. If your org has Data Cloud enabled, this feature automatically captures execution duration, success/failure status, and fault details without manually setting up debug logs. It's worth checking whether this is available in your org, especially for ongoing monitoring rather than one-time checks.

What's Next

If your flow is in the warning or critical range, the debug log tells you what you need to know. The next question is what to do about it. Our post on when Flow breaks and how to know it's time for Apex covers the five signals and the recommended move for each one. And our Technical Debt Calculator can help you prioritize which flows to address first.

Digital Mass is a developer-led Salesforce consultancy that architects and builds the automations, integrations, and technical foundations that enterprise Salesforce orgs depend on. If you're evaluating Agentforce for a healthcare environment and want to make sure the architecture supports compliance from day one, let's talk.