New Transparent capture is in preview. Record every app's traffic with no proxy configuration, on Windows, macOS and Linux. Learn more

stdOutAction Action

Write text to stdout from inside a Fluxzy rule, with variable interpolation, to feed pipelines, dashboards, or live debugging sessions.

Streaming a one line summary per matching exchange turns Fluxzy into a tiny observability tool. Pipe the output into grep, awk, or your favorite line based aggregator, and you have a live filter view of the only requests that matter to you.

When to use this action

Use stdOutAction to emit a line of text on standard output every time a filter matches. The action supports {{variable}} substitution, which lets you build readable summaries that include the URL, status code, host, or any variable you previously set with setVariableAction.

Typical uses:

  • Stream a tcpdump style log of matching exchanges into a pipeline that searches or counts them.
  • Print a one line summary per slow response while a load test runs.
  • Surface specific events during a manual debugging session so you do not have to flip between the UI and the terminal.

Pair the action with a tight filter, because stdout can fill quickly. If you only care about a subset of the lifecycle, use runScope to restrict execution to one stage of the exchange.

Real world examples

Log every request to a host with method and path

Lightweight tail style logging you can pipe into grep or jq friendly tooling.

rules:
- filter:
    typeKind: HostFilter
    pattern: api.example.com
  actions:
  - typeKind: StdOutAction
    text: "{{method}} {{authority}}{{url}}"

Print response status codes for a single path

Use a runScope so the line is emitted after the response header is parsed, when the status code is known.

rules:
- filter:
    typeKind: PathFilter
    pattern: /checkout
  actions:
  - typeKind: StdOutAction
    text: "checkout response: {{statusCode}}"
    runScope: responseHeaderReceivedFromRemote

Combine stored variables with live values

Capture a tenant id once with setVariableAction and reuse it in every log line for that exchange.

rules:
- filter:
    typeKind: AnyFilter
  actions:
  - typeKind: SetVariableAction
    name: tenant
    value: acme
  - typeKind: StdOutAction
    text: "tenant={{tenant}} url={{url}}"

Reference

stdOutAction

Description

Write text to standard output. Captured variable are interpreted.

Evaluation scope

Evaluation scope defines the timing where this filter will be applied.

outOfScope Means that the filter or action associated to this scope won't be trigger in the regular HTTP flow. This scope is applied only on view filter and internal actions.

YAML configuration name

stdOutAction

Settings

The following table describes the customizable properties available for this action:

Property Type Description DefaultValue
text string
runScope nullable`1 When RunScope is defined. The action is only evaluated when the value of the scope occured.

Example of usage

This filter has no specific usage example

.NET reference

View definition of StdOutAction for .NET integration.

See also

The following actions are related to this action:

Frequently asked questions

What variables can I interpolate in the text?

Exchange properties such as url, authority, method, statusCode, and any variable you previously defined with setVariableAction or applyTagAction. Variables not yet available on the current scope render as empty strings.

How is this different from fileAppendAction?

stdOutAction writes to the process stdout stream and is best for ad hoc inspection or piping. fileAppendAction persists the same text to a file on disk for long term capture.

Can I control exactly when the line is written?

Yes. Set the runScope property to a specific stage such as responseBodyReceivedFromRemote. Without runScope, the action runs at the scope inherited from its filter.

Will this slow down a heavy capture?

Standard out is fast on Linux and macOS, but uncontrolled logging in a high traffic environment can fill the terminal or fill a container log volume. Use tight filters and limit the action to interesting subsets.

Learn more about Fluxzy rules