You answer for uptime you do not own.

You answer for the availability of systems you do not own, and you have to prove it to each client on its own terms. Perstat keeps every client separate inside one organization: projects, white-label status pages on their domain, and read-only API keys scoped per client. No separate tool per account.

You carry the pager for other people’s systems. One client’s storefront, another client’s checkout API, a third client’s marketing site on a stack you did not build. When one of them fails at the wrong hour the call lands on you, and the next morning that same client wants to see that you were watching, in numbers, about their systems and nobody else’s.

The trap is one tool per client: a monitoring login here, a status-page vendor there, a spreadsheet of certificate dates you keep meaning to update. Perstat is built to hold every client in one organization and still show each of them only their own record.

One organization, one project per client

Monitors live in projects. Put one project per client and the boundary follows the work: that client’s checks, that client’s incidents, that client’s history, grouped and legible instead of one flat list of every monitor you run.

That project boundary is also where you hand out read access. API keys are read-only today and scoped: narrow a key to a single project, or to individual monitors, and a key you drop into a client-facing dashboard returns that client’s monitors and nothing else. Seven read endpoints are live, enough to pull monitors, checks, response-time series, and incidents into whatever you already run. Write access is selectable but not honoured yet, so monitors are created in the app, not as code.

Be clear on what this is not. Projects group and scope; they are not a tenant login. Your client does not sign in to Perstat and see a private console of their own. What faces the client is the status page and any dashboard you build with a scoped key. That is usually what an agency wants, but it is worth knowing before you promise a client their own seat.

A status page in each client’s brand

Every client wants proof that faces their users, not yours. From the Command plan, status pages are white-label: the client’s logo, light and dark, with no Perstat branding on the page. Each page can run on the client’s own domain, status.theirbrand.example, verified by CNAME or TXT with TLS issued automatically at the edge; Sentinel carries 3 custom domains per page, Command 10. A page can be public, or gated behind a shared password or named viewer accounts when a client would rather not put their uptime on the open web.

Each page shows an uptime window the client picks, from 7 to 365 days, drawn from the same measured record that drives your alerts, so the number a client reads is the number you were paged on. Two honest limits. Notification and subscriber emails still send from Perstat’s domain, not from status@theirbrand.example ; sending from a client’s own domain is on the roadmap, not shipping today. And the page count has a ceiling: up to 5 status pages on Sentinel, 20 on Command, unlimited on Enterprise, which is the line to check if you run one page per client at scale.

The expiries nobody puts on a calendar

The outage that embarrasses an agency is rarely exotic. It is an expired TLS certificate, or a domain that lapsed because the renewal notice reached an inbox nobody reads. Across forty client domains that is forty dates you are tracking by hand, or not tracking at all.

Perstat watches them as checks. An ssl_cert check reports certificate expiry, issuer, and self-signed certificates; a domain check reads NS, SOA, DNSSEC, and WHOIS expiry. Point them at every client domain and a lapsing certificate or an expiring registration becomes a warning weeks ahead, on the same board as everything else, instead of a Saturday.

For your own team the cockpit and the wallboard put the whole fleet on one screen, live over a persistent stream, every client’s state at a glance. A fleet that size only stays livable if it does not cry wolf, which is the point of the alert rule: an incident opens only after probes in more than one region confirm the failure, and within a region 75% of its nodes have to agree before the region votes at all. One flaky route on one client’s site does not reach your phone, and a divergence below that bar lands on a watchlist you read on your own schedule. Five hundred monitors do not become five hundred false alarms.

Proving it, and where Perstat stops

What you hand a client is the status page above and the record behind it: uptime windows over real measured data, a curated outage history where a false positive is discarded with a reason and its effect on the number is previewed before it applies, announced maintenance kept separate and not counted against them. There is a copyable uptime badge and a sample SLA report you can show a client as a template. Read that report as illustrative: a one-click SLA export is the announced next step, not a button you press today.

Now the part that decides whether Perstat fits your business. Perstat has no reseller portal and no per-client billing. You hold one Perstat contract and you are the billed party; the separation between clients runs through projects and white-label, not through tenant invoicing you can resell line by line. If your model needs Perstat to bill each client directly under your brand, that does not exist. If you need to watch many clients, keep them apart, and prove each one separately from one place, that is the exact shape of the product.

Start with one client

Pick your messiest account, the one whose site, shop, and mail all break on different days. Put their systems in one project and point a status page at their domain. That is the whole model in miniature, and it runs on the free plan before you scale it.

Start monitoring free . Or see pricing , every number on the page. Or take the tour , no signup.