Production checks

Run a browser check against production only when a flow’s real deployment must be verified. Local, preview and staging targets are the default. Blop never infers production from a branch, configuration or environment name: you choose the target with --base-url or a reviewed baseUrl.

Prerequisites

Before you enable a production check, confirm every item:

The target is explicit and reviewed.
A dedicated least-privilege synthetic identity exists.
Every write is reversible or has tested cleanup and a TTL.
Payment, messaging, webhooks and other external effects are sandboxed or accepted by the owning team.
Synthetic traffic is identified, rate-limited and easy to stop.
Artifact contents, access, upload destination and retention are reviewed.
An operator owns failures and cleanup alerts.

Run a production check

pnpm exec blop test run tests/production-smoke.blop.ts \
  --base-url https://app.example.com \
  --report-dir .blop/production-smoke

Start manually, observe several clean checks, then schedule conservatively.

Check it worked

The command exits 0, .blop/production-smoke/results.json shows passed, and every synthetic record the check created is gone after cleanup.

Use a synthetic identity

Create dedicated synthetic users, service accounts and isolated test tenants. Never automate a customer account.
Grant only the permissions the flow needs. Do not use owner, billing, support impersonation or global administrator roles.
Keep credentials in the CI or runtime secret store, never in the goal, the repository, screenshots or the command line.
Make synthetic records recognizable without secrets or personal data, for example with a reserved tenant and email domain.

Bound side effects

Prefer read-only checks. For writes, use idempotent or reversible operations.
Define cleanup for every created cart, project, order, file or invitation. Run it on success, failure and timeout, and add a TTL backstop.
Never use real payment credentials. Use the payment provider’s test mode or a production path built for synthetic transactions.
Inventory email, SMS, webhook, analytics, fulfilment, support and other third-party effects. Disable, sandbox, reroute or explicitly accept each one.
Exclude destructive account, tenant, data-export and administrator flows by default.

Control execution

Keep the target URL and the allowed set of checks in reviewed configuration.
Rate-limit and identify synthetic traffic so operators can separate it from customers and stop it quickly.
Avoid broad crawls. Run the smallest check that proves the claim.
Provide a kill switch by disabling the schedule, workflow or credentials, and document who owns it.
Do not send trace context to production hosts unless the check is deliberate and safeguarded; see OpenTelemetry export.

Protect evidence

Browser evidence can contain names, account details, URLs, console output, DOM text and tokens. Treat screenshots, progress files, results.json, events.jsonl and uploaded report bundles as production data.

Capture as little evidence as you need and keep retention short.
Review goals and assertions so they do not echo credentials or personal data.
Restrict artifact access to the operators who need it.
Confirm the Blop Cloud project and ingest credentials before upload. Local telemetry and check runs in Blop Cloud are separate stores.
Review this policy again whenever the flow, permissions, target or third-party integrations change.