Logging in Scout tests

This page explains how logging works in Scout: the log fixture used inside tests, and how to inspect logs from the systems under test (Kibana, Elasticsearch, the browser, and UIAM) when running against a serverless project in MKI.

log is a fixture available in every Scout test, for logging from the test process itself — separate from the server-side logs of the systems under test (Kibana, Elasticsearch, and so on), covered later on this page.

Standard levels are available: error, warning, success, info, debug, and verbose. Prefer debug for ad hoc diagnostic logging in your test — avoid adding info-level logs too liberally, since info is the default level and prints on every run.

Use it inside a test or fixture like any other fixture:

test('does the thing', async ({ log }) => {
  log.debug('detailed state: %o', someState);
});
		

You'll see this output in your local console, in the Buildkite job log for CI runs, and in the Scout HTML report (attached to each test, under Output Logs):

Scout's own services and fixtures log their setup at the debug level (for example, [serviceName] loaded), so if you want to see fixture wiring and lifecycle messages, run with debug (see below).

Under the hood, log is backed by ScoutLogger, a thin wrapper around @kbn/tooling-log's ToolingLog. Each worker gets its own logger instance tagged with a context string, and messages are written to stdout.

The log level is resolved in this order:

1. An explicit logLevel passed when constructing the logger (rarely done outside Scout internals)
2. The SCOUT_LOG_LEVEL environment variable
3. The LOG_LEVEL environment variable
4. The default level, info

The value is case-insensitive. The recognized values are silent, info, debug, and verbose; other ToolingLog levels such as error, warning, and success are not recognized here and fall back to the default info. Note that quiet is normalized to error internally, but because error itself is not recognized, SCOUT_LOG_LEVEL=quiet also currently falls back to info rather than restricting output to errors.

Default locally and in CI: info. There is no CI-specific override — Buildkite pipelines don't set SCOUT_LOG_LEVEL, so CI runs use the same info default as a local run unless you set the variable yourself.

To get more verbose output (for example, fixture/service lifecycle messages), run with:

SCOUT_LOG_LEVEL=debug node scripts/scout run-tests \
  --arch stateful \
  --domain classic \
  --config <plugin-path>/test/scout/ui/playwright.config.ts
		

See also Debug Scout test runs for other debugging tips.

• Log sparingly. When a test fails, the assertion failure (expected/received, stack trace) usually already tells you what went wrong — you don't need to log every step to diagnose it.
• Prefer interactive debugging over log statements when working locally. Playwright UI mode or breakpoints often get you to the root cause faster than adding log.debug calls and re-running.

When Scout starts a local Kibana/Elasticsearch stack (for example via node scripts/scout start-server), server logs print directly to that same console by default. To capture them to files instead, pass --logToFile, which writes kibana.log and es-cluster-<name>.log under a generated directory in data/ftr_servers_logs/ (yes, ftr_servers_logs — Scout reuses the legacy FTR server-management code and its log directory naming).

This only applies to servers Scout manages directly (local runs). It doesn't apply when running against Cloud (ECH) or MKI serverless projects — see the next section for how to find server logs in that case.

When a Scout test runs against a serverless project in MKI, the project's own server-side logs aren't printed to your local console and Scout doesn't manage the servers directly — they're shipped to Elastic's internal Overview cluster.

Access: the Overview cluster is a separate organization from your personal QA cloud account, so you likely won't see the relevant data by default. Request readonly access to it (for example, via an internal access-request tool) before you can query it.

Where to look: in the Overview cluster's Kibana, open Discover and select the discover-observability-solution-all-logs data view (broader than the default data view — it's backed by a remote logging cluster via cross-cluster search). Filter to your test project with:

serverless.project.id : "<your-project-id>"
		

You can cross-check with the equivalent Kubernetes-level fields on the same documents if needed:

kubernetes.labels.k8s_elastic_co/project-id : "<your-project-id>"
kubernetes.namespace : "project-<your-project-id>"
		

Retention on this data view is roughly on the order of weeks for Kibana/Elasticsearch logs and longer for UIAM logs, but treat this as approximate — it's governed by ILM policies that can change, so check the actual index list if you need a precise cutoff.

• Kibana logs — server-side logs from the Kibana instance backing the serverless project. Filterable by serverless.project.id. Useful fields: log.level, log.logger, message.
• Elasticsearch logs — server-side logs from the project's Elasticsearch cluster, same pipeline/schema as Kibana logs and filterable by serverless.project.id.
• UIAM logs — logs from the Unified Identity and Access Management service, useful when investigating auth-related test failures in serverless (where UIAM handles API keys and identity, unlike the local environment). UIAM is a shared regional service, so these logs are not tagged with serverless.project.id — correlate them to your project via a known user identity or token visible in the log message instead.

Scout's UI test fixtures capture browser console errors during a test run and attach them to the failure report and test artifacts when a test fails. You can find them in the Scout HTML report, alongside the rest of the test's artifacts — there's no separate console output to watch for these locally.

The Overview cluster's discover-observability-solution-all-logs data view (see above) does not currently include raw browser/RUM application logs for MKI runs — only synthetic monitor results, which are a different thing.