I’m doing per-module latency profiling on webhook-triggered scenarios (voice AI tool calls, so seconds matter) and I’m trying to pin down the exact semantics of the gray “+Xs” badges in the execution log detail. I can’t find them defined anywhere in the Help Center — the execution cycles/phases article describes initialization → cycles (operation + commit/rollback) → finalization, but not the time badges.
What I observe:
Advanced log: badges appear on some lines and not others. External I/O modules (HTTP, LLM calls, Gmail) get badges like +2.1s on “The operation used 1 credit”; routers, filters, and JSON parses show no badge at all.
Simple log: each module gets one “operation was completed” row, and the badge there roughly matches the Advanced log’s operation badge for the same module.
Trigger module rows are the confusing part: my Custom webhook row shows +2.7s (another run +4.8s) in the Simple log, while the Advanced log shows its “module was initialized” line at +0.6s — and a webhook receive should be near-instant.
My questions:
Is the Advanced-log badge the time elapsed since the previous log entry or the duration of the event on that line?
What’s included in the trigger module’s time — queue delay before the execution started? The module’s open-to-commit span (the webhook’s commit closes at the very end of the cycle)?
Do “module was initialized” badges mean initialization cost scales with blueprint size (my scenario has ~200 modules and shows ~1–3s of badges before “Cycle #1 was started”)?
Is there a display threshold (looks like nothing under 0.1s gets a badge)?
Has anyone confirmed this with Make staff, or found official documentation? Happy to share fuller log excerpts if useful.
Can’t speak for Make’s internals, but I profile webhook scenarios a lot and most of these four questions can be settled empirically in about 15 minutes, so here’s how I’d approach it:
Delta vs duration: drop a deliberately slow module between two fast ones (an HTTP call to a slow endpoint, or Tools > Sleep for 5s) and watch where the +5s shows up. If it lands on the slow module’s own line, badges are durations. If it lands on the next line, they’re elapsed-since-previous-entry. This would also explain your trigger discrepancy: +2.7s in the simple log vs “initialized at +0.6s” in advanced logs is consistent with the simple view rolling queue wait and init into one number while advanced logs anchor each entry separately.
Trigger time composition: put a client-side timestamp inside the webhook payload itself (sent_at from whatever fires it). Then compare three numbers: your sent_at, the received time in the webhook queue history, and the first module timestamp in the run log. That splits network plus queue delay from actual module open-to-commit time without guessing.
Init scaling: clone the scenario, delete half the modules, fire the same payload at both, compare the gap before “Cycle #1 was started”. Two data points beat any documentation. With ~200 modules I’d expect init to scale with blueprint size (the whole graph gets parsed and validated before the run), but the clone test tells you how much, and whether it’s linear.
Sub-0.1s threshold: your observation already looks close to conclusive. Easy confirmation: find one module that consistently takes 0.2-0.3s and one under 0.1s, run a few times, and see if the badge appears and disappears at the same boundary every time.
One general note from profiling voice scenarios: measure across several runs at different times of day before trusting any single number. Queue wait on shared infrastructure varies far more than module execution time, and one run can mislead you about where the latency actually lives.
Happy it helped! If you end up running the delta vs duration test, I would be curious which way it comes out. Post the numbers here if you do, it will help the next person who searches for those badges.
I submitted a ticket with support and I just viewed their response. Here is what they sent me:
The gray "+Xs" badge shows the time elapsed since the previous log entry.
You can inspect the execution log JSON through your browser’s Developer Tools:
Open your browser’s Developer Tools and affected execution in Make.
Open the Network tab,
Search for the relevant log ID.
Open the corresponding log JSON response.
Review the time values recorded for each log entry
These values are shown in milliseconds from the start of the scenario execution. Comparing two consecutive values allows you to calculate the exact interval between those events.
1. In the Advanced log, the "+Xs" badge represents the time elapsed since the previous log entry. It does not directly show the duration of the event.
2. In the Simple log, some technical entries are hidden. Because of this, the value shown on the Custom webhook completion row may include scenario initialization, connection setup, and blueprint validation that occurred before the webhook module completed. This explains why a webhook may show +2.7s or +4.8s even though the webhook operation itself is nearly instant.
3. Initialization covers connecting to the app and validating the scenario’s blueprint (its structure/config). It typically happens once for the whole scenario and most modules do not show a timing badge on this line. This duration does not necessarily increase directly with the number of modules, but it may be affected if an external service (e.g. a self-hosted database or SFTP server) is slow to respond. That delay shows up here and can make this step take noticeably longer.
4. The interface displays badges for intervals of "0.1s" or longer. Shorter intervals are still recorded with millisecond precision but are not shown as separate badges in the UI.
At this moment, that is all the information we can provide about the execution-log. I hope this explanation makes the timing information clearer.
Thanks for looping back with the official answer, that confirms the simple log rolling init and connection setup into the webhook row. The JSON tip is the most useful part for your case: diff the time values per module and you get real millisecond numbers for your voice profiling instead of eyeballing 0.1s badges. Cleaner than the clone tests I suggested.