Results & CI Batches

Synthetics → Results searches every run of every monitor, and every CI batch. Pick the scope at the top: Monitor runs or CI batches.

Monitor Runs

Filter runs with the search bar or the facets: Status, Type, Monitor, Location, Probe, Failure (error type), HTTP status, Run type (scheduled, CI) and labels. The search bar takes status, check_type, monitor, location, probe, failure_code, http_status, run_type and batch_id.

Pick a view:

For the charts, pick a Measure (Duration, DNS, Connect, TLS, TTFB), an Aggregation (count, avg, max, p50, p75, p90, p95, p99), a Group by (Monitor, Location, Status, Type, Failure, Run type and more), and the sort and limit.

Open in Data Explorer opens the same runs in the Data Explorer, where they can be combined with your logs, traces and metrics and added to dashboards.

CI Batches

A CI batch runs a set of monitors once, on demand, typically from a CI/CD pipeline after a deployment, and passes or fails as a whole. CI runs never alert, open outages or change uptime.

Each monitor's CI execution rule (in the editor's Locations & schedule step) decides how it counts:

The CI batches list

Filter by Status (passed, failed, running, timed out), Provider, Repository, Branch, Pipeline and Suite, or search by commit SHA. Click a batch to see its provider, repository, branch, commit, pipeline and job, author, duration and overrides, and each monitor's rule, status, locations and duration. View runs lists the batch's runs.

Running a batch from a pipeline

Batches are started with synthetics-cli, published as the public image public.ecr.aws/p8w3i6u3/synthetics/cli. It selects monitors, waits for the batch, writes a JUnit report and exits non-zero when a blocking monitor fails.

It calls the KubeSense API with a KubeSense API key (see Creating an API key). The key's user needs write access to Synthetics and editor access to the monitors it runs. Store the key as a masked CI secret, and set the API URL to your KubeSense address.

docker run --rm --user "$(id -u):$(id -g)" -v "$PWD:/work" -w /work \
  -e SYNTHETICS_API_URL=https://kubesense.example.com \
  -e SYNTHETICS_API_KEY \
  public.ecr.aws/p8w3i6u3/synthetics/cli:latest \
  run --labels env=staging \
      --override variables.BASE_URL=https://staging.example.com \
      --wait --timeout 15m --junit synthetics-junit.xml

- name: Synthetic tests
  env:
    SYNTHETICS_API_URL: ${{ vars.KUBESENSE_URL }}
    SYNTHETICS_API_KEY: ${{ secrets.KUBESENSE_API_KEY }}
  run: |
    docker run --rm --user "$(id -u):$(id -g)" -v "$PWD:/work" -w /work \
      -e SYNTHETICS_API_URL -e SYNTHETICS_API_KEY \
      -e GITHUB_ACTIONS -e GITHUB_SHA -e GITHUB_REF_NAME -e GITHUB_REPOSITORY \
      -e GITHUB_WORKFLOW -e GITHUB_JOB -e GITHUB_ACTOR -e GITHUB_SERVER_URL -e GITHUB_RUN_ID \
      public.ecr.aws/p8w3i6u3/synthetics/cli:latest \
      run --labels env=staging --wait --junit synthetics-junit.xml

synthetics:
  stage: test
  image:
    name: public.ecr.aws/p8w3i6u3/synthetics/cli:latest
    entrypoint: [""]
  # SYNTHETICS_API_URL and SYNTHETICS_API_KEY (masked) are CI/CD variables.
  script:
    - synthetics-cli run --labels env=staging --wait --junit synthetics-junit.xml
  artifacts:
    when: always
    reports:
      junit: synthetics-junit.xml

Selecting monitors — one of --ids a,b, --labels k=v[,k=v], --search text or --types HTTP,TCP.

Overrides apply to this batch only, with --override key=value (repeatable):

Other options — --api-key and --api-url (instead of the environment variables), --wait (wait for the result), --timeout (batch timeout, up to 30 minutes), --junit / --json (reports), --fail-on-timeout (default on), --fail-on-missing, --fail-on-critical, --config synthetics.json (the same options as a file). synthetics-cli batch get <id> prints a batch and writes its reports.

The CLI reads GitHub Actions and GitLab CI environment variables and attaches the repository, branch, commit, pipeline and job to the batch, so they show in the CI batches list.