---
title: Browser check variables and secrets (process.env) in WatchFor
description: Keep URLs, usernames, passwords, API tokens and 2FA secrets out of your Playwright scripts — organisation variables and encrypted secrets, read as process.env and masked in logs, traces and screenshots.
canonical: https://watchfor.io/docs/monitors/browser-checks/variables
---

# Browser check variables and secrets (process.env) in WatchFor

Keep URLs, usernames, passwords, API tokens and 2FA secrets out of your Playwright scripts — organisation variables and encrypted secrets, read as process.env and masked in logs, traces and screenshots.

Scripts read values as `process.env.NAME`, exactly as they would on your laptop.
The values live in **Settings › Variables & secrets**, shared by every browser
check in the organisation, so a password changes in one place.

```ts
await page.getByLabel('Email').fill(process.env.LOGIN_USERNAME!);
await page.getByLabel('Password').fill(process.env.LOGIN_PASSWORD!);
```

## Variables and secrets

| | Variable | Secret |
|---|---|---|
| Stored | as text | encrypted at rest |
| Shown again | yes, to members | never — not to owners either |
| In logs, errors, step titles, trace text, screenshots | as written | masked as `••••••` |
| Use for | usernames, URLs, search terms | passwords, API tokens, TOTP secrets |

- Names use capital letters, digits and `_` and start with a letter
  (`LOGIN_PASSWORD`), up to 64 characters. Values up to 4 KB.
- Every member can see the variable list (they write scripts); owners and
  admins add, change and delete them. A secret's value can be replaced, never
  read back.
- Only the variables a script references travel with its runs. Other checks'
  values are never sent along.

**`TARGET_URL`** is built in: it is always the check's own URL, so one script
can watch staging and production as two checks.

The same variables work in **HTTP, API and MCP checks**: type `{{NAME}}` in an
auth field, a header value or the request body (`Bearer {{API_TOKEN}}`). See
[Web checks → Credentials and variables](/docs/monitors/web#credentials-and-variables).

## In the editor

The **Variables** strip under the editor lists what the script reads:

- a check mark or a lock — the variable or secret is set;
- **amber** — the script reads it but it isn't set, so the run gets `undefined`;
  click it to add it with the name filled in;
- **dashed, "fallback"** — not set, but the script has its own fallback
  (`process.env.NAME ?? 'value'`) or treats it as optional.

The examples start on public practice sites with those sites' published values
written in the script. **Use my site** turns them into `process.env` reads and
tells you which to add, and which as secrets. A real password never has to be
typed into a script.

## Where masking stops

Masking replaces the exact secret value wherever it appears in text the run
produces, and covers the area of a screenshot where the value is shown. Two
things it can't know about:

- a **different** value derived from a secret — a hash, a token the site issues
  after sign-in, the secret split across two fields. Cookie and
  `Authorization`-style headers are redacted in the trace, but a token the site
  returns in a response **body** (a JSON `access_token`, say) is kept in the
  trace's Network tab, where every member of the organization can open it. Use a
  dedicated monitoring account, or turn the trace off for that check;
- a page that **displays** a secret in clear text can still appear in the
  trace's film strip. Turn **Keep a Playwright trace** off in the check's
  Settings if that can happen.

Don't `console.log` secrets; if you do, the log shows `••••••`.

## Who can use a secret

Nobody can read a secret back — not owners either. But a script runs with the
secrets it names in `process.env`, and a script can send a value anywhere on the
public internet. So anyone who can **change or test-run a script** can use a
secret: owners and admins, API keys with the write scope, and agents working
through those keys. Members can read scripts and runs but can't edit or run
them. Give write keys only to tools you trust.

## From code

Manage variables over the API (`GET /v1/variables`, `PUT /v1/variables/{name}`,
`DELETE /v1/variables/{name}`) or the SDK's `variables` namespace — see
[API, MCP and SDK](/docs/monitors/browser-checks/api). A secret's value is
write-only there too.

---

Canonical page: https://watchfor.io/docs/monitors/browser-checks/variables · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt