Monitor the real user flows your business is built on

Write the flow once and parameterize it. A Playwright spec that loops over a tenants array produces one test per tenant from a single file, with per-tenant credentials injected as environment variables. Group the resulting checks by tier or by owning team so alerting and reporting follow the same shape.

In encrypted environment variables, set at the check, group, or account level and never committed to the repo. Your spec reads them from process.env, so the same suite runs locally, in CI, and as a production monitor without a credentials file changing hands.

Yes. Point URL monitors or browser checks at each customer domain and Checkly will also track SSL certificate expiry, which on a white-label setup is a failure mode that tends to surface as a support ticket rather than an alert.

That is the usual reason teams move to Checkly. Checks are TypeScript files that live in the service repo, so they are reviewed in the same pull request as the code they cover. Each group routes to its own alert channels, so the team that owns the service is the team that gets paged.

Yes. Status pages publish the checks you choose on your own domain, and dashboards can be shared with a link or embedded. Enterprise customers asking for evidence of uptime can be pointed at a page rather than sent a spreadsheet.

The checks do. Point a check at a status page service with triggerIncident and the incident opens when the check fails, notifies subscribers, and resolves when it recovers. Status pages can be public or private, so a named enterprise account can have a restricted view while the general page stays broad. Nobody is writing customer updates by hand while also trying to fix the thing.

Traces and Rocky AI, plus the fact that you are running the flow per tenant rather than in aggregate. Checks emit OpenTelemetry spans, so a failing tenant login links to the backend request behind it, which separates a bad SSO configuration from a shared service degrading for everyone. Rocky AI reads the run alongside that trace and returns a plain-language cause, including whether the fault is scoped to one account. That answer decides whether you page anyone and what you publish.

No, and it should not. It is the same suite doing a second job. The tests that gate a merge in CI are the tests worth running against production every few minutes, so you maintain one set of specs and point Checkly at the tags you want monitored.