# Production checks

> Run a deliberate browser check against production without touching customer data or causing real side effects.

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

```bash
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](/checks/ci/#export-browser-check-telemetry-with-opentelemetry).

## 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.

## Next

- [Browser checks in CI](/checks/ci/)
- [Browser Harness security model](/harness/security/)