Checks
Strands Version
latest
Installation Method
pip
Steps to Reproduce
- Enable OTEL tracing (e.g. with Langfuse as the backend)
- Run an agent that performs multiple event loop cycles (e.g. an agent that calls a tool and then returns a final answer — minimum 2 cycles)
- Inspect the resulting trace spans for
execute_event_loop_cycle
Expected Behavior
Each execute_event_loop_cycle span should reflect only the wall-clock time of that specific cycle iteration. Individual span durations should roughly sum to the total agent invocation time. This is how the TypeScript SDK behaves (confirmed working correctly).
Actual Behavior
Span durations are reported as a reverse-running cumulative total. The first cycle's span encompasses the time of all subsequent cycles, producing a monotonically decreasing staircase:
| Cycle |
Reported Duration |
| 1 |
2m 28s |
| 2 |
2m 21s |
| 3 |
2m 2s |
| 4 |
1m 55s |
| 5 |
1m 44s |
| 6 |
1m 31s |
| 7 |
34.26s |
| 8 |
22.17s |
| 9 |
8.75s |
Total agent invocation was ~2m 29s. The durations don't add up from a user perspective, causing confusion in observability dashboards.
Additional Context
- This issue may have been present since the initial release of OTEL tracing in the Python SDK.
- The TypeScript SDK does not exhibit this behavior — spans are correctly scoped per-cycle there.
- This has generated customer confusion/tickets because timing data appears nonsensical in dashboards.
Possible Solution
The start_time for each execute_event_loop_cycle span is likely being set to the beginning of the overall loop rather than the start of each individual iteration. Fix the span creation so start_time is captured at the top of each cycle iteration.
Related Issues
Checks
Strands Version
latest
Installation Method
pip
Steps to Reproduce
execute_event_loop_cycleExpected Behavior
Each
execute_event_loop_cyclespan should reflect only the wall-clock time of that specific cycle iteration. Individual span durations should roughly sum to the total agent invocation time. This is how the TypeScript SDK behaves (confirmed working correctly).Actual Behavior
Span durations are reported as a reverse-running cumulative total. The first cycle's span encompasses the time of all subsequent cycles, producing a monotonically decreasing staircase:
Total agent invocation was ~2m 29s. The durations don't add up from a user perspective, causing confusion in observability dashboards.
Additional Context
Possible Solution
The
start_timefor eachexecute_event_loop_cyclespan is likely being set to the beginning of the overall loop rather than the start of each individual iteration. Fix the span creation sostart_timeis captured at the top of each cycle iteration.Related Issues