xgress3

Appearance

Request logging ​

xgress3 records traffic at three separate layers. They serve different purposes and retain different data.

LayerWhere it livesWho uses it
Request Lookupxgress3 platform (console)Operators troubleshooting ingress
Agent log filesAgent host ({data-dir}/logs/)Agent administrators
Platform operational telemetryxgress3 operations (not in the console)xgress3 support and reliability

Request Lookup (tenant ingress) ​

Request Lookup stores metadata about HTTP requests that reach your service hostnames:

text
https://{account_id}--{service_id}.{region}.xg3.io/{path}

This includes:

  • Successful relays to your backend
  • Gateway-side outcomes such as authentication failure, agent unavailable, rate limits, and similar errors (when a record is written)

Request Lookup does not include regional platform endpoints such as OAuth token minting, agent enrollment, or JWKS. Those flows are outside Request Lookup.

Every response from a service hostname includes X-Xg3-Request-Id. Use that value in the console Request Lookup menu to find the matching record.

Records are retained for 7 days, then expire automatically.

Always stored (metadata) ​

For each recorded request, xgress3 stores:

FieldNotes
X-Xg3-Request-IdSame value as the response header
HTTP method, path, query stringQuery is stored as part of request metadata
Backend base URLConfigured service backend (not the public hostname)
Response HTTP statusFrom your backend when relayed, or gateway outcome when denied
TimingStart and completion timestamps
Relay outcomeWhether the request was relayed, denied, rate-limited, etc.
Account, service, agent identifiersWhen known
Auth mode and credential/key idJWT or service key mode, plus an opaque credential/key id — not the secret or token value

Never stored in Request Lookup ​

  • Client request headers (including X-Xg3-Authorization and X-Xg3-Service-Key)
  • Client request body

Authentication headers are used only for the live authorization decision and are not persisted in Request Lookup records.

Optional capture (per service) ​

On the service detail page you can enable:

  1. Capture backend response — store backend response body (when relay succeeds)
  2. Full header logging — store backend response headers (requires response capture)

Both toggles must be enabled together.

When enabled:

  • Response bodies up to 1 MB may be stored; larger bodies are truncated or flagged as too large
  • Sensitive response headers (Authorization, Cookie, Set-Cookie, Proxy-Authorization, X-Xg3-Authorization, X-Xg3-Service-Key) are stored as [REDACTED]

Disable these options when you are not actively troubleshooting. Captured backend data may contain sensitive application content.

Console access ​

  • Request Lookup — search by X-Xg3-Request-Id and view metadata (method, path, query, status, timing, outcomes)
  • Captured response body — visible only to roles your account admin grants for that purpose; metadata lookup and body viewing are separate capabilities

Agent logs ​

The xg3 Agent writes rolling log files on the agent host under {data-dir}/logs/. These logs are not uploaded to Request Lookup.

See Install and run — Log files for location, rotation, and RUST_LOG verbosity.

Platform operational telemetry ​

xgress3 retains operational logs, traces, and metrics to run the service and assist with support. This telemetry is separate from Request Lookup:

  • Operational HTTP traces do not include URL query strings or HTTP header values
  • Request Lookup metadata may still include query strings on the request path

Avoid placing secrets or personal data in URL query parameters when possible.

Privacy guidance ​

  • Query strings in Request Lookup may contain PII or opaque identifiers — treat records like application logs for data classification
  • Optional response capture may contain sensitive backend payloads — enable only for short troubleshooting windows
  • Share X-Xg3-Request-Id with teammates or support rather than pasting full URLs with query parameters when avoidable