Every client in their own room

The problem with one flat list of monitors

Past about a dozen sites, a single list of monitors turns into a spreadsheet you have to filter in your head. Alerts for one client’s shop land in the same channel as another’s blog, the report you want to send is mixed with everyone else’s, and the idea of giving a client a login is a non-starter because they would see all the others. A client workspace is a container that fixes that. It is an Agency feature ($59 per month, with up to 1000 monitors), and in the comparisons we made it is something other tools do not sell at all.

What lives inside a workspace

A workspace owns the monitors assigned to it, its own alert contacts if the client wants alerts of their own, its status pages and their branding, and the settings and recipients of its monthly report. Your own team sees every workspace; a viewer sees exactly one. Monitors, contacts and status pages always belong to your account first and optionally to one workspace, so nothing is copied and moving a monitor between clients keeps its history.

Routing follows the same layering. A monitor uses the contacts you set on it, and if that list is empty it falls back to the defaults, with the workspace defaults checked before the account defaults. Telegram alerts include the client’s name, so the on-call person knows whose problem it is before opening anything.

Setting up your first ten clients

Create a workspace under Clients, give it a name, an optional logo and the client’s domain. Then bring monitors in. For existing monitors, select several in the list and use Move to client; for new ones, create them from inside the workspace so they are assigned from the start. A reasonable pattern for an agency:

• One workspace per paying client, named exactly as it appears on your invoice, so support and billing talk about the same thing.
• A workspace for your own sites, so your internal monitors do not clutter a client’s report.
• Default contacts set per workspace: the client’s technical contact on email, your own team in a shared Telegram group.
• A status page per workspace on the client’s domain, covered on the status pages page.

Viewer logins: what the client can and cannot see

Invite a client contact as a Viewer and they get a login that opens straight into their workspace in read-only mode. They see monitor status, incidents, response times, status pages and reports. They do not see other clients, billing, or the alert contacts that belong to your team. They cannot change anything, so there is no risk of a client pausing their own monitor before a bad week.

Agency has unlimited seats, which matters here: viewers are people, and agencies with sixty clients do not want a per-seat tax on giving each of them a window into their own data. Viewer API keys are scoped to their workspace in the same way, so a client with a developer can pull their own data without getting yours.

Reports and the 1st of the month

Each workspace has its own monthly report, with the client’s logo and your footer, emailed to the recipients you set on the 1st and optionally to all viewers of that workspace. That per-client behaviour is Agency only; Pro produces one branded report for the whole account. See client reports for the contents.

Edges and things we do not do

A monitor lives in at most one workspace, and workspaces are flat: there are no sub-clients or nested groups, so a client with three brands is either one workspace or three. Clients cannot create monitors themselves. Billing is a single account-level subscription; Tenium does not invoice your clients, you bill them however you like. If your needs are one company with several departments rather than an agency with clients, regular team seats on Pro will probably serve you better.

The programmatic side is exposed as client_workspaces in the REST API, and monitors carry a clientWorkspaceId, which is useful if you provision a new client from your own onboarding script. For positioning and pricing the service, read Tenium for agencies.