Roles that match how agencies work
Admins configure endpoints and triage incidents. Members watch and report. Membership is per workspace.
Multi-tenant uptime monitoring
Every client’s uptime.
One console.
Each client gets an isolated workspace, its own endpoints and incident history,
and a public status URL at /status/<client>. Operators sign
in to the workspace they belong to, keeping each client’s dashboard separate.
Self-hostable. Runs on Postgres. No agent to install on anything.
Example deployment
Northwind Logistics
/status/northwind
128ms
Meridian Health
/status/meridian
214ms
Kestrel Payments
/status/kestrel
96ms
Alder & Vane
/status/alder
342ms
Illustrative workspaces. Names and figures are examples, not customers.
Public status, rendered
This is the product, not a stock dashboard.
Status pages render service state, uptime figures, history bars, certificate warnings, and incidents from workspace records. The separate live demo is backed by scheduled HTTP checks.
Org-isolated
One workspace per client. Nothing bleeds across.
Endpoints, incidents, maintenance windows, users and reports all belong to an organization. A client’s data is scoped to their workspace at the query level, not hidden in the interface.
Its own status URL
Every workspace publishes to /status/<client> — a page you can hand a client without exposing anything else.
Onboarding is one form
Creating an account creates the workspace with it. No provisioning step, no seats to allocate before you can start watching something.
GET · POST · PUT · PATCH · DELETE · HEAD · OPTIONS
Check what your clients actually run.
Real systems need more than a GET against the homepage. Authenticate the check, send a body, and assert on what comes back.
Headers
Bearer tokens and API keys per endpoint, as JSON or plain Header: Value lines.
Body
Send a payload with POST, PUT and PATCH checks — exercise the endpoint the way a client does.
Assertions
Match an expected status code, and require a string in the response body. A 200 that returns the wrong thing is still an outage.
Cadence
Per-endpoint intervals and timeouts. A payments API can run every 30s while a marketing site runs every 5 minutes.
SLA · P90 · 7 / 30 / 90 days
Reporting a client will actually read.
Uptime against the windows that appear in service agreements, and latency measured at the percentile that shows the problem. Averages hide the bad tail; P90 is where a client’s complaint lives.
A digest that lands before the client asks
Every workspace can send its team a weekly SLA summary on Monday morning. Send it early and the uptime conversation is already had.
Incidents with a paper trail
Investigating, identified, monitoring, resolved — each with timestamped updates and the services it touched, kept against the workspace.
Public · per client
A status page for each client, at /status/<client>.
When something breaks, a client’s customers go looking. Give them a page to find: current state per service, the check history, and the incident timeline — updating live, without a refresh.
Open a live status pageStart with one client workspace.
Create a workspace, point it at an endpoint, and watch the first check land.
Create a workspaceQuestions
StatusPulse, without the sales fog.
The practical details agencies and self-hosters usually need before creating a workspace.
Can one user switch between client workspaces?
No. A user belongs to one workspace, which keeps each client dashboard and its operational data separate.
What can an HTTP check validate?
Checks support seven HTTP methods, custom headers, request bodies for POST, PUT, and PATCH, expected status codes, response-text assertions, intervals, and timeouts.
How long is check history retained?
The hosted deployment retains check logs for 90 days, matching the longest reporting window. Other workspace records are stored separately.
What does StatusPulse cost?
There is currently no software subscription charge. Self-hosters pay for their own infrastructure and any third-party services they choose.