Workspace setup
Get a workspace ready for real monitors, from who has access to a tested alert path.
Everything here happens before your first monitor. Budget ten minutes.
Quickstart is the first-monitor walkthrough. This page is the workspace around it.
Finish onboarding#
Signup collects your name, company, title, and acceptance of the Terms and Privacy Policy. Marketing consent is optional and separate.
A first project is created for you, so you land on a working dashboard rather than an empty one.
Understand what a project is#
A project is the boundary for monitors, members, notification groups, and status pages. A member of one project cannot see another project's monitors unless someone adds them.
Assign the right role#
| Role | Can do |
|---|---|
OWNER | Everything, including billing settings and deleting the project |
MANAGER | Manage monitors, channels, groups, and members. Create and revoke API keys |
MEMBER | Work with monitors, acknowledge and resolve incidents |
READONLY | View only. Cannot acknowledge incidents |
READONLY is the right role for stakeholders who need to see current status without being able to change alerting. Giving a manager who "just wants visibility" a MANAGER role is how alert routing gets changed by accident.
Invite your team#
- Open the project's settings.
- Choose Invite Member.
- Enter the email address.
- Pick one of the four roles.
- Send.
Owners and managers can invite. An invitation adds the person to that project only, never to everything you own.
Enforce 2FA on production projects#
Drumbeats supports per-user TOTP, and projects can require it.
With enforcement on, a member who has not enrolled is blocked from the project, and the REST API returns TOTP_REQUIRED_FOR_PROJECT for them until they do.
Turn it on for production and anything customer-facing. Enrol yourself first, or you will lock yourself out of your own project.
Wire and test notifications#
A monitor with no notification group records incidents and pages nobody. Nothing about the monitor's state hints that this is what is happening, so it is worth doing before you rely on anything.
- Add a channel. See notification channels.
- Click Test on it and confirm the message arrives.
- Create a group for the responsible team and add the channel.
- Attach the group to every production monitor.
Check this before you go to production#
| Check | Why |
|---|---|
| Onboarding finished, project named | Cosmetic, but a project called "My Project" ages badly |
| Roles reviewed | Nobody has more access than the job needs |
| TOTP enabled on your own account | Prerequisite for enforcing it on anyone else |
| Decision made on project-level TOTP | Enforce on production, optional elsewhere |
| At least one channel tested | An untested channel is a guess |
| A notification group exists and is attached | Without it, incidents page nobody |
| A real alert round-trip completed | Send a manual failure ping, confirm the alert, then a success |
That last row is the one people skip and the one that catches actual problems. Two curl commands.
Next#
Quickstart to create the first monitor. Billing lifecycle for how owner-wide billing behaves after an upgrade. REST API for API keys and permission scopes. Security for the posture behind these roles.