Skip to main content
This feature is in preview. The API may change before general availability. To try it out, contact support@intunedhq.com and we’ll enable it for your workspace.
Stop Intuned from recording part of an attempt. While tracing is paused, the browser trace, screenshots, and automation logs are not captured—so sensitive values your automation types or reads never reach a stored trace. Use it around the few lines that touch secrets: filling a password, entering a one-time code, or reading a record you aren’t allowed to retain.
Pausing tracing is narrower than turning tracing off. saveTrace discards the trace for a whole Run, which also removes the trace you need to debug the other 99% of the automation. Pause when you only need a gap.

Available helpers

Function reference

tracing_paused

An async context manager that pauses tracing for the body of the async with block and resumes it on exit. Tracing resumes even if the block raises, so a failure in the middle of a sensitive step can’t leave the rest of the attempt unrecorded. Prefer this form. Reach for pause_tracing only when the sensitive work spans function boundaries—for example, pausing in a hook and resuming in your automation.
The TypeScript SDK exposes this as withTracingPaused(callback) instead, so it reads naturally in each language.
Returns Returns an async context manager. The block’s own value is unaffected. Example

pause_tracing

Pauses tracing for the current attempt until resume_tracing is called. Calling it while tracing is already paused does nothing.
If your code raises between pause_tracing and resume_tracing, tracing stays paused for the rest of the attempt and you lose the trace for everything after that point. Use try/finally, or use tracing_paused instead.
Returns Returns None. Example

resume_tracing

Resumes tracing for the current attempt. Calling it while tracing is already active does nothing. Returns Returns None.

What pausing covers

While tracing is paused:
  • Browser trace — No actions, DOM snapshots, or network requests are recorded. The trace viewer shows a gap.
  • Screenshots — No screenshots are captured, including the ones taken automatically around actions.
  • Automation logs — Anything your code writes to stdout or stderr is dropped rather than stored on the attempt.
What is still recorded:
  • The Run and Attempt records themselves—status, timing, and retry history.
  • Your automation’s return value, and the Run’s parameters. Tracing has no effect on either. To keep a value out of the Run record entirely, use ephemeral parameters.
  • Errors. A raised exception’s message and traceback are still stored on the attempt, even if it was raised while tracing was paused.
Never put a secret in an exception message. Error details are stored on the attempt regardless of tracing state.

Behavior notes

  • Nesting works. Nested tracing_paused blocks are safe; tracing resumes when the outermost block exits.
  • Scope is the attempt. Tracing state resets at the start of every attempt, so a retry always begins with tracing active.
  • Local development included. The helpers behave the same under intuned dev, so a locally captured trace has the same gaps a deployed one would.
  • Ephemeral parameters pause automatically. get_ephemeral_parameter pauses tracing on your behalf before it returns a value.