Everything you need to catch broken customer journeys

Uptime monitoring pings a URL and checks if it responds. A workflow check navigates your product like a real customer — filling in forms, clicking buttons, and verifying that the right things happen. It catches the bugs that exist when your site is "up" but broken.

You can have your first check running in under 10 minutes. Pick a journey, define the steps, add a couple of assertions, and schedule it.

Yes. Every failure alert includes a screenshot of the page at the moment the check failed, so you can immediately see what went wrong.

Uptime checks typically verify that a URL responds (often just HTTP 200 + latency). Workflow checks validate the full customer journey—e.g., signup → email verification → login → checkout—so you catch failures that still return 200s (broken forms, auth redirects, JS errors, missing buttons, payment failures, or API schema changes). This is especially useful for SaaS where the app can be “up” while key flows are unusable.

Use layered assertions: (1) page-level: URL/redirect expectations, status codes, and core text present (e.g., “Welcome back”); (2) element-level: button enabled, field visible, modal closed; (3) data-level: API response contains expected JSON keys/values; (4) business outcome: user lands on /app after login, invoice created, subscription status becomes “active”. Pair assertions with screenshots and console/network error capture so alerts include evidence, not just “failed.”

Retries should be configurable and intentional: retry only on flaky failure modes (timeouts, transient DNS, intermittent 5xx), and avoid retrying on deterministic failures (assertion mismatch like missing element text). A good pattern for small teams is 1–2 quick retries (e.g., 10–30s apart) plus alert on first failure for high-impact flows (login/checkout), while lower-impact flows can alert after retries to reduce noise.

Yes, but plan for the auth method: for session-based apps, store encrypted credentials/secrets and validate post-login assertions; for OAuth, use dedicated test tenants and service accounts; for magic links/OTP, integrate with a test inbox (or API-based email provider) and assert the link/token is consumed. For 2FA, many teams use a bypass in test environments or a dedicated TOTP seed stored as an encrypted secret. Always isolate synthetic users from real customer data and apply least-privilege roles.

Route by impact and ownership: send P1 flows (signup/login/billing) to a shared Slack channel with @oncall mentions; send lower-severity issues to email or a triage channel; use webhooks to create issues (Jira/GitHub) only after a sustained failure window. Include run metadata in alerts (step failed, assertion message, screenshot link, last successful run, region) so the first responder can act without asking for more context.

Screenshots turn “it failed” into a concrete UI state: error banners, blank pages, unexpected modals, consent screens, captcha triggers, or layout shifts that hide buttons. Capture at least on failure, and optionally at key milestones (post-login, pre-checkout, post-payment). For SPAs, also capture console errors and failed network requests—many workflow breakages come from JS exceptions or blocked API calls that still return HTTP 200 for the shell page.

Prefer stable selectors (data-testid) over brittle CSS/XPath, and assert on invariant signals (URL patterns, key headings, presence of critical buttons) rather than exact copy. Pin the synthetic user to a known experiment cohort where possible, disable experiments for test accounts, and set locale/timezone explicitly. For dynamic values (timestamps, prices with discounts), assert ranges or patterns instead of exact matches.