Quiet when it works, detailed when it fails

By default the tunnel logs only requests that fail or return a 5xx, with their headers. That keeps the log readable in normal use and self-diagnosing when a test breaks. When you need more, turn up browser traffic and the Selenium relay independently.

Since v5.0

Where logs go and how much

Option	Effect
-l,--logfile <FILE>	Also write the log to a file.
--log-level <LEVEL>	`error`, `warn`, `info` (default), `debug` or `trace`.
-d,--debug	Alias for `--log-level debug`.
--log-http <MODE>	Per-request HTTP logging, see below.
--log-format <text\|json>	Plain text (default) or one JSON object per record.
--request-id-header <NAME>	Header carrying the correlation id. Default `X-Request-Id`.

java -jar testingbot-tunnel.jar --logfile tunnel.log --log-level debug

HTTP request logging

--log-http controls how much of each proxied request is written to the log.

Mode	Logs
errors	Default. Request line and headers, only for failed or 5xx responses.
none	Nothing per request.
url	One line per request. This was the 4.x behaviour.
headers	Every request with its headers.

java -jar testingbot-tunnel.jar --log-http url

Browser traffic and the Selenium relay, separately

The tunnel carries two kinds of traffic: the proxy (requests the cloud browser makes to your sites) and the forwarder (the Selenium relay on port 4445 that your test talks to). Set a level for each with proxy: and forwarder:.

# debugging a WebDriver problem: silence page traffic, show every command
java -jar testingbot-tunnel.jar --log-http proxy:none,forwarder:headers

# debugging a page that will not load: the opposite
java -jar testingbot-tunnel.jar --log-http proxy:headers,forwarder:none

forwarder:body also logs the relay's request body. That body is WebDriver capabilities, which routinely carry your access key, so it is redacted before it is written (see redaction). proxy:body is refused: browser traffic has to stream and cannot be buffered for logging.

Request IDs

Every request carries a correlation id. It is printed in brackets on each log line and passed to your server in the X-Request-Id header.

If the incoming request already has that header, its value is reused. That lets you match a line in the tunnel log to a line in your application's access log. Use a different header name if your stack expects one:

java -jar testingbot-tunnel.jar --request-id-header X-Correlation-Id

JSON output

--log-format json writes one JSON object per record, so a log collector does not have to guess where a multi-line message or a stack trace ends.

java -jar testingbot-tunnel.jar --log-format json --logfile tunnel.jsonl

Useful when the tunnel runs in Docker or Kubernetes and its output is shipped to Loki, Elasticsearch, Datadog or CloudWatch.

What is redacted

Tunnel logs often end up attached to support tickets and CI artifacts, so credentials are removed before anything is written.

Header values that carry credentials, such as Authorization, Proxy-Authorization, cookies and TB-Credentials.
Credentials in URLs: the user:password@ part and credential-shaped query values.
In forwarder:body, values whose key names look like credentials. A body that cannot be parsed, because of an unknown content type or because it is too large, is described rather than printed.

Sharing a log with support? Include the output of --doctor as well, it usually saves a round trip. See troubleshooting.