Sign inCreate a free account
Theme

Workspaces and team

Separating work, and deciding who can see it.

A workspace is a container for work on a site: its tracked pages, its history, its crawls, its uptime monitors and its members. One account can hold several, which is how an agency keeps one client's work separate from another's.

Workspace members, with their roles.

When you need more than one

SituationArrangement
One siteOne workspace. Never think about this again.
Several of your own sitesOne workspace is usually still right. History filters by host, so the sites stay legible.
Client workOne workspace per client. It is the only way to give somebody access to their own site and nothing else.
Separate teams internallyOne per team, so each has its own tracked pages and monitors without competing over the same list.

Members and roles

People are invited by email. An invitation is to a specific workspace, so somebody working on one client's site never sees another's.

RoleCanCannot
OwnerEverything, including billing, plan changes and deleting the workspace.
AdminAll the work, plus inviting and removing members.Touch billing or delete the workspace.
MemberRun analyses, track pages, start crawls, read everything.Manage members, billing or workspace settings.
ViewerRead reports and history.Run anything or change anything.

Give a client Viewer. They see their reports and their history, which is usually the whole point of showing them, and they cannot spend your monthly allowance by running crawls.

Seats

A seat is a person, not a workspace. The same colleague in four workspaces is one seat. Pro includes 3, Agency includes 10, and extra seats can be added to either.

Allowances are the workspace's, not the person's. Five people in one workspace share its monthly reports rather than getting their own, which is worth saying out loud before a team of five starts crawling on the same afternoon.

Switching

The workspace switcher is in the dashboard header, and everything below it changes with it: the tracked pages, the history, the crawls, the monitors. API keys belong to a workspace too, so a key made in one client's workspace can only ever read that client's data.

Removing people

Removing a member revokes their access immediately, including any active session, and does not touch the work they did. Reports they ran stay in the workspace history, because that history belongs to the workspace rather than to the person.

Ownership can be transferred to another member, which is the correct way to hand a workspace to a client or to a colleague. The previous owner stays as an admin unless they are removed.

Type to search. Try a check name from your report, an endpoint, or what you are trying to do.

↑↓ to move ↵ to open Esc to close