Simple pricing for small SaaS teams

Yes, upgrade or downgrade anytime. Changes take effect immediately and billing is prorated.

Not yet, but it's on our roadmap. Monthly billing means you can try it risk-free and cancel anytime.

Yes. On Team and Growth plans, you can run checks against multiple environments (production, staging, etc.).

We'll let you know and give you the option to upgrade. We won't suddenly stop your existing checks.

A check is the workflow you define (e.g., “Login → Create invoice → Download PDF”). A run is each execution of that workflow on a schedule or trigger. Most pricing models in the market charge per check (how many workflows) and/or per run (how often you execute them), sometimes with add-ons for locations, retries, and higher-frequency schedules.

Uptime tools typically price per monitored URL/host with simple HTTP/TCP checks. Workflow/transaction monitoring often prices by runs because browser/API steps consume more compute and generate more telemetry (screenshots, traces, logs). For small SaaS teams, the key cost driver is usually frequency (e.g., every 1 minute vs every 5–10 minutes) and number of locations, not the number of teammates.

Start by mapping workflows to business risk. Revenue-critical flows (signup, login, checkout, billing) often justify 1–5 minute cadence; internal/admin flows can run every 15–60 minutes. A practical approach is tiered frequency: run a fast API smoke check every 1–2 minutes and a full browser workflow every 5–15 minutes. This catches outages quickly while keeping run volume predictable.

In many tools, yes. Retries can multiply run consumption, multi-region execution can multiply it again, and rich artifacts (screenshots/video/har files) may be included or may increase storage/retention costs. When comparing plans, look for how “run units” are counted (scheduled run + retries, per-location multipliers) and what’s included for artifact retention.

Per-check pricing is predictable when you add workflows slowly but can discourage monitoring “nice-to-have” flows. Per-run pricing is predictable when you keep frequency and locations stable, but costs can jump if you move from 5-minute to 1-minute checks or add regions. The most small-team-friendly setup is usually: a small number of high-value workflows, clear caps on run volume, and simple add-ons when you need more frequency or locations.

Yes, but do it carefully. Use dedicated test accounts, sandbox environments (e.g., Stripe test mode), and stable test data. Avoid high-frequency actions that look like abuse (e.g., repeated password resets, repeated card authorizations). Prefer read-only or idempotent steps where possible, and rate-limit workflows. For auth providers, use test tenants and avoid MFA flows unless you can automate them safely.

Look for pricing that’s transparent about overages or auto-upgrades. In practice, small teams often increase frequency during incidents, which can cause unexpected run consumption. A good pricing model either (1) allows burst capacity with clear overage rates, (2) provides hard caps with graceful throttling, or (3) supports incident-mode schedules that are time-boxed so you can safely increase coverage without a surprise bill.