Website checks

Use a page Check for availability or visible content. Use a Playwright Check for a journey: a search result appears, a consent choice is respected or a form handles a failed submission. Setup is saved in Pulse; neither approach needs a Checks SDK or a siteos.config.json file.

Check a page

With CLI 2.49 or newer installed, select the Project and environment, then create a Check:

siteos project use <project-id> --environment production
siteos project connect pulse
siteos pulse native save --name "Homepage" --slug homepage --kind http --path / --cadence 900 --json

Connect Pulse only if it is not already attached. This Check requests the selected environment's homepage every 15 minutes. No repository or local test installation is required. Use --kind page to check that the page renders visible text in a browser. Without --cadence, the Check runs only when requested.

Read siteos pulse native list --json before editing an existing Check; updates require its ID and current revision. An HTTP pass proves the page responds. It does not prove a form or account flow works.

Start with one useful journey

Select the Project environment, then reuse an existing Playwright test or ask your agent to create one. Use base-URL-relative navigation so the same test can target your website or a PR preview:

import { expect, test } from "@playwright/test";

test("documentation search finds a guide", async ({ page }) => {
  await page.goto("/docs");
  await page.getByRole("searchbox", { name: "Search documentation" }).fill("installation");
  await expect(page.getByRole("link", { name: "Installation", exact: true })).toBeVisible();
});

Adapt the route, accessible names and expected result to your website. Prefer stable assertions over fixed delays. Mock form delivery in routine monitoring so the check does not create leads or send messages. Give any deliberate delivery canary its own manual Check.

Validate and publish

Keep your ordinary Playwright config, specs and fixtures. Run the test locally against the intended website, then save its paths in Pulse:

PLAYWRIGHT_BASE_URL=https://your-website.example pnpm exec playwright test tests/search.spec.ts
siteos pulse playwright attach --name "Documentation search" --slug documentation-search \
  --config playwright.config.ts --files tests/search.spec.ts --json
siteos pulse playwright publish --check <check-id> --dry-run --json

Use the returned Check ID. A dry run prepares an immutable snapshot locally without uploading it. Imported local helpers are included automatically; declare files loaded dynamically with --assets. Select projects and tags with repeated --project and --tag options.

The runner supports Chromium, Playwright and Node built-ins. Configurations that require a local app server, unsupported external packages or an empty test selection fail explicitly. Keep any local webServer conditional on PLAYWRIGHT_BASE_URL being absent so remote checks use the deployed website.

When ready to update the selected environment:

siteos pulse playwright publish --check <check-id> --json
siteos pulse checks read --check <check-id> --json

Publication queues a verification run. Pulse activates the snapshot only after it discovers tests and they pass; failed verification keeps the current active version. Follow the returned Run ID, then inspect the active version, schedule and PR participation. A queued run is not a completed publication.

A manual remote run executes the published browser Check, not local edits:

siteos pulse run --check <check-id> --json

Use the saved Check ID returned by Check reads. Follow the returned run in SiteOS or through the agent's run-reading tools. Remote execution consumes the applicable allowance and may perform real actions on the target website.

Choose when it runs

Choose schedules and PR participation in Pulse. An interval has a minimum of 60 seconds. Weekly schedules use selected days, local time and timezone. Inspect the displayed next run after a change. Publishing a snapshot preserves existing scheduling overrides. A manual schedule stops recurring runs; it does not disable PR checks. Pausing Project monitoring also leaves PR verification independent.

Code Checks retain their version 4 repository configuration and are PR-only; see their separate guide.

Update tests automatically

Connect the Project repository through Services → GitHub. In Repository & deployments, use Find deployments in GitHub to review environment suggestions. The optional Website deployment environment limits which environment can update this website's tests. There is no separate hosting-provider connection.

Enable automatic updates for an existing Check:

siteos pulse playwright list --json
siteos pulse playwright attach --check <check-id> --revision <current-revision> \
  --auto-refresh --json

For a new Check, add --auto-refresh to its first playwright attach command. Pulse checks for updates at most once every five minutes. The newest matching GitHub deployment must be successful, its URL must match the bound website exactly, and its source SHA must belong to the selected branch. A rollback to an older deployed commit is supported; a newer unshipped commit cannot replace the tests.

Hosting providers that already report this evidence need no build change. Other systems configure the successful-publication notification once. An immutable preview URL alone does not prove that a release serves the production domain. The per-Check --refresh-environment <name> option overrides the repository binding's environment filter when needed.

Pulse prepares updated tests, verifies them on its runner and rechecks deployment evidence before activation. Missing evidence or a failed candidate leaves the current version active; inspect the Check's refresh and candidate state for the reason. You do not manually publish tests after each deployment.

To verify the connection after setup, publish an ordinary website change. Compare the full source SHA in GitHub's successful deployment with the Check's refresh source SHA in Pulse. The active candidate must have a passing verification run. If the test files have not changed, Pulse can reuse the same test version while advancing the recorded source SHA; a new version number is not required. The Check ID, history, schedule and PR participation stay the same.

Automatic updates follow deployed source. For a deliberate test-only update that must remain independent of the deployed commit, disable refresh with --no-refresh, then publish the Check explicitly.

Migrate existing checks

Existing manifest-managed Checks continue to work. To move a browser Check to saved Playwright setup:

siteos pulse playwright list --json
siteos pulse playwright migrate --check <check-id> --revision <current-revision> --dry-run --json
siteos pulse playwright migrate --check <check-id> --revision <current-revision> --json
siteos pulse playwright publish --check <check-id> --json

Migration preserves the Check ID, history, active version, schedules, overrides and PR participation. Verify the new candidate before removing its obsolete manifest entry. Keep siteos.config.json while code Checks or other unmigrated Checks still use it.

Use variables and Secrets

A Playwright Check declares required names with --variables 'TEST_LOGIN,SESSION_TOKEN' when saving its setup. Owners and admins set the values for each environment in Pulse → Settings → Variables & secrets; saved Secrets are write-only and never stored in the snapshot. A Check with missing values waits instead of failing. Runs that use Secrets save restricted diagnostics, and PR runs never receive variables or Secrets.

Follow an incident

The preview below uses synthetic data to illustrate detection, notification and recovery. It is not a live report. Real monitoring confirms a failure through the policy described below.

Read monitoring health

The first eligible scheduled assertion failure marks a Check as needing attention. A second consecutive eligible failure opens an incident. An eligible scheduled pass resolves it.

Manual runs, PR runs, cancellations and infrastructure errors do not open or resolve scheduled monitoring incidents. A runner error means the result is unavailable, not that the website is broken. Use the saved failure reason to decide what needs attention.

Check history and pass ratios describe the executed checks; they are not a contractual website uptime percentage. Missing runs, a paused schedule and a passing manual check are different states. Inspect the effective schedule and latest scheduled evidence when verifying recovery.

Maintain the checks

When a journey changes, reproduce the behavior before updating the assertion. Review the change, validate locally, publish the new version and inspect the next authorized run. Do not turn a failing expectation into a passing one without confirming the intended website behavior.

For preview checks, follow GitHub setup. For failed steps, recordings, traces and notification routing, use Evidence & alerts.