Skip to main content

Upkeep Performance Tests

In brief: Upkeep-perf maintains k6 journeys and composites from history, baselines, and relative TrueCoverage demand—preserving stable test ids, refreshing redacted contracts, and never deriving absolute load from telemetry.

:::tip Authoritative product docs Performance Testing · when to use which workflow. This page is the agent playbook. :::

Upkeep Performance Tests (workflow-id: upkeep-perf) is the k6 analog of /testchimp upkeep. It does not replace per-PR run-perf-tests or first-time create-perf-tests.

When to use​

  • On a cadence (weekly / after a cluster of PRs), as APIs and scenarios drift.
  • After several journeys landed that should join or leave a composite.
  • When thresholds fail for the wrong reason—stale contract, dataset, or mock latency—not when you want to hide a real degrade.

Do not use it to author the first journey for a PR (create-perf-tests), to execute a release git range (run-perf-tests), or to “fix” a regression by weakening thresholds or dropping stub latency to 0 ms.

Prompt​

/testchimp upkeep-perf
/testchimp maintain performance tests
/testchimp upkeep-perf for checkout

Synonyms: /testchimp upkeep-perf, /testchimp maintain performance tests.

Scope​

Optional. When omitted:

  • Feature / PR branch — journeys related to the branch diff.
  • Default branch — changes since the last upkeep-perf run (related selection + coverage gaps).

Related selection (list-related-perf-tests + select-related.sh) drives the candidate set. You can name an area or files.

Prerequisites​

  • Org capability PERFORMANCE_TESTING (or trial).
  • Existing k6/ catalog. If the tree is missing, you want init-perf first.
  • connect-to-test-env for smoke (and any approved load/volume re-run).
  • upkeep-perf.policy.md plus run-perf-tests.policy.md for capacity and mock inventory.

Policy​

Default: plans/knowledge/policies/upkeep-perf.policy.md.

Records what may change without extra approval. Composite membership and threshold weakening always appear explicitly on the approved plan. TrueCoverage never authorizes a new VU budget.

How to use​

  1. /testchimp upkeep-perf (optionally for authentication). Read the plan: selected journeys, reasons, history/baseline ids, proposed metadata vs logic vs membership vs threshold changes.
  2. Approve only the checklist items you want. Decline silent SLO loosening.
  3. After Execute, re-run smoke on touched journeys; load and volume via k6/scripts/run.sh on the approved isolated env.
  4. Compare new ingest to the approved baseline on matching dimensions (results UI or compare-perf-to-baseline).

What it does​

Plan → approve → Execute → Validate → Report:

  1. Flags stale #TS-… links and high-priority scenarios with no PERF_TEST coverage.
  2. Refreshes redacted REAL E2E shapes; never persists raw interaction values. Synthetic seeds only.
  3. Uses list-perf-runs / list-perf-baselines / compare-perf-to-baseline (nonzero exit when regressed). Diagnoses drift vs true degrade.
  4. Prompts every composite add/remove/weight (relative mix only).
  5. Preserves stable testchimp.id across moves—branch copies are not distinct tests.
  6. Re-audits outbound mocks on touched journeys; never “fixes flake” by dropping latency to 0 ms.
  7. Smoke-validates first; then k6/scripts/run.sh for approved load/volume, only against the approved environment.

See also​

FAQ

How is upkeep-perf different from upkeep?

Upkeep maintains SmartTests and plans. Upkeep-perf maintains the k6 suite—journeys, composites, datasets, mocks, and thresholds—using the same Analyze → Plan → Execute envelope.

Will upkeep-perf raise VUs because TrueCoverage showed more traffic?

No. Demand is a relative ranking signal only. Absolute load and threshold weakening always need explicit approval.

Can it rename a journey id?

It must preserve stable testchimp.id values across moves. Branch copies are not treated as distinct tests.

Related documentation