Teams

Share monitors with the people who fix things — without handing over your account.

What a team is

A team is a named group of people you invite by email, plus the monitors you choose to share with them. It does two jobs in Enori:

Sharing. A monitor you share with a team becomes visible to every member of that team, at the level their role allows.
Paging. Escalation policies and on-call schedules are built on top of a team — a policy's recipients must be members of the team the policy belongs to.

Everything else stays yours. A teammate never sees your other monitors, your alert channels, your billing, or your incidents.

You can be in two kinds of relationship with a team:

	What it means
Owner	You created it (or it was transferred to you). The team counts against your plan. You are the only person who can invite, remove, change roles, share monitors, edit and delete.
Member	Someone invited you and you accepted. You can see what has been shared with the team, act on it per your role, and leave whenever you like.

Ownership is not a role you assign. There is exactly one owner per team and the only way it changes is Transfer ownership. The roles you hand out are Viewer and Editor — those two, and no others.

The two roles

When you invite someone, or change an existing member's role, you pick one of these:

Role	What it grants on the monitors shared with the team
Viewer	View shared monitors and their results
Editor	Also edit, pause and run checks

Those are the descriptions the invite form itself shows you, and they are exact. Below is the same boundary in full detail.

What a Viewer can do

Open a shared monitor and see its configuration, current status, response times, uptime figures and check history
Read its stats for any range, its daily and hourly rollups, its SSL and security-header state, its DNS baseline
Snooze the monitor for themselves. A snooze mutes alerts for the person who set it, not for the rest of the team — see Alerts → snooze. Other members see a quiet line saying who snoozed it and until when.

One deliberate omission: a Viewer on a shared Job monitor does not receive its ping token. That token is what lets anything POST a heartbeat, so a read-only role would otherwise be able to forge job runs.

What an Editor can additionally do

Everything a Viewer can, plus, on shared monitors:

Edit the monitor's configuration, and pause or resume it
Check now (subject to your own plan's manual-check allowance)
Start and end a maintenance window on it
Create, edit, enable, disable and delete its SLOs
Create and manage its trace RED alert rules
Mark individual check results and job pings as resolved, and annotate them with notes
Re-run the analysis on a browser check, accept or revert a browser self-healing suggestion
Trigger a reputation or security-header check, reset the security-header baseline, refresh the DNS baseline
Manage an API-flow monitor's variables

What neither role can do

Delete the monitor. Deletion is owner-only, always.
Share it further, or stop it being shared. Both are owner-only.
See who else it's shared with. The share list is owner-only.
Open or acknowledge the owner's incidents from the dashboard. See below — an escalation page is the one route that does reach them.
See the owner's alert channels, other monitors, invoices, API keys or settings.

Incidents stay with the monitor's owner

This is the boundary that surprises people most, so it is worth stating plainly:

Incident management stays with the monitor's owner — teammates cannot open or acknowledge incidents from the dashboard. An escalation policy built on the team can still page them, and the Acknowledge link in that page works.

Incidents are scoped to the account that owns the monitor. In the dashboard and the API a teammate cannot list them, cannot open one, cannot acknowledge or resolve one, and cannot write a post-incident review — an Editor included. Neither role changes any of that.

What a teammate does get when a shared monitor goes down is the notification: a bell entry and a mobile push, the same event the owner sees, minus the inline Acknowledge / Snooze / Resolve buttons that appear on the owner's copy. So the team knows; the paperwork stays with the owner.

Two narrow exceptions, so this page isn't overstating it.

An SLO breach row carries an incident's title and timing. An SLO on a shared monitor lists its recent budget-burning events, and where one of those rows comes from an incident it carries that incident's title and timing. That is coherent — the SLO is about the shared monitor — but it means "teammates never see anything about an incident" would be false.

An escalation page's Acknowledge link works. If the owner's escalation policy pages a teammate, that page carries a one-click Acknowledge link, and clicking it acknowledges the incident for real — it stops the escalation ladder exactly as the owner's own Acknowledge does. Nothing about the teammate's role grants this: what grants it is holding the signed, single-use, 48-hour link the owner's own policy sent them. It is the supported way to put a colleague on the pager, and it is described below.

If you need a teammate to handle incidents

Two options, both real:

Escalate to them. An escalation policy built on the team pages its members through their own channels, and they can acknowledge from the link in the page — a real acknowledgement that stops the ladder, not a receipt. That is the supported way to put a colleague on the pager. What they still cannot do is open the incident in the dashboard, add updates to it, or resolve it.
Let them own the monitor. If someone else should own an outage end to end, the monitor should live in their account.

Plan limits

	Base	Pro	Business
Teams you own	2	10	∞
Members per team (including the owner)	3	10	25

Two things about the member cap that are easy to get wrong:

The owner counts. A Base team with a cap of 3 has room for the owner plus two other people.
Pending invitations count. An invitation you sent that nobody has accepted yet occupies a seat. Cancel it and the seat comes back.

The cap is checked when you invite, and again when the invitee accepts. That second check is not redundant: if you downgrade your plan between sending an invitation and someone accepting it, the accept is refused with "This team is full (N/M members). Ask the owner to upgrade their plan." rather than silently pushing you over your plan.

Hitting either cap returns a message naming the numbers — "Member limit reached (3/3)", "Team limit reached (2/2)" — and an upgrade prompt. Your current usage against these limits is on Settings → Usage (Account & Settings).

Creating a team

Teams in the sidebar, under Collaborate → Create Team.

Field	Notes
Team Name (required)	Up to 100 characters.
Description	Optional, up to 500 characters. Shown on the team card.
Members	Type an email and press Enter (or comma) to add it as a chip. Pasting a comma- or space-separated list adds them all at once. Backspace on an empty box removes the last chip.
Member Role	Appears once you've added at least one email. Viewer or Editor — one choice, applied to every email in the list.

You are added as the team's first member automatically, and you are its owner.

Everyone you listed gets an invitation, not a membership. Nobody is in the team until they accept.

If you need different roles for different people, invite them one at a time from the team's page afterwards, or invite everyone as Viewer and promote the ones who need Editor.

Invitations

Sending one

Open the team → Invite → type an email address, pick Viewer or Editor → Send Invitation.

Two ways the invitee finds out:

An email with an Accept Invitation button, which lands them on the invitation page.
A bell notification, if they already have an Enori account. A team invitation is the one notification you can act on directly in the bell — Accept and Decline appear inline while it's unread. See Notifications.

The dashboard also shows a banner at the top — "You have N pending team invitations" — to anyone with invitations waiting.

They don't need an account first

An invitation can go to an address that has never used Enori. The invitation page offers Sign In and Create Account, and returns them to the invitation once they're in.

What they do need is to be signed in as the invited address. Accepting (or declining) while signed in as somebody else is refused with a message naming the account you're actually signed in as, and telling you to sign back in with the invited one. This is deliberate — an invitation grants access to another person's monitors, so it is bound to one address.

Expiry, resend, cancel

An invitation expires 7 days after it is created. An expired one can't be accepted; send a new one.
Resend — in the team's Edit dialog, beside each pending invitation. It re-sends the email and gives the invitation a fresh 7 days.
Cancel — on the team page beside the invitation, or in the same Edit dialog. Only a pending invitation can be cancelled or resent; one that has already been accepted, declined, cancelled or expired can't.

"EMAIL NOT DELIVERED"

The invitation is written to your account first and the email is sent afterwards, so "invitation created" has never meant "email arrived". When Enori knows the email did not go out — the mail provider rejected it — the pending-invitation row gets a red EMAIL NOT DELIVERED badge, and the Edit dialog says "Email not delivered — resend to try again".

Read that badge literally, in both directions:

Its presence means the invitee received nothing. The invitation itself is perfectly valid — hit Resend, or send them the link yourself.
Its absence is not a delivery receipt. It means the mail provider accepted the message. A bounce that happens afterwards, or a message that lands in spam, is not something Enori can see. If someone says they never got it, resend rather than assume.

Sharing is owner-to-owner: to share a monitor with a team you must own the monitor and own the team. There is no way to share a monitor into someone else's team, and no way for a member to share their own monitors into a team they merely belong to.

Two places to do it:

From the team — open the team → Share a Monitor → pick from your monitors that aren't already shared with it.
From the monitor — the monitor's Share dialog lists the teams you own, and the teams it is already shared with.

A monitor can be shared with several teams at once. A member who is in more than one of them gets the highest access any of those teams grants — Editor in one team and Viewer in another means Editor.

Removing a share (the ✕ beside the monitor on the team page, or in the monitor's Share dialog) revokes access immediately.

Be deliberate here — sharing is not scoped to "from now on":

The monitor's full history, including check results from before it was shared.
The monitor's full activity history in the Audit Log, including configuration changes made before it was shared. The Share dialog says so on the spot.
Every field of the monitor's configuration, including any custom headers or request bodies you have set on it.

What the team sees afterwards

Members get a Shared Monitors section on the team page, and the monitor appears in their own Monitors list carrying a banner — "Shared with you via team «name» · Owner: …" — that says either "You can edit this monitor" or "You have view-only access".

They also start receiving bell and push notifications about it: the monitor going down and recovering, certificate and domain expiry warnings, SLO burn-rate alerts, and config events (shared / unshared / updated). Those notifications are written once per person, so marking yours read changes nothing for anyone else.

They do not start receiving your alert channels. Email, Slack, Discord, Teams, webhook and PagerDuty messages go to the channels you configured on the monitor. The only way an outbound alert reaches a teammate's own channels is an escalation policy that targets the team, or an on-call schedule built on it.

Managing members

Everything in this section is owner-only. A member opening the team page sees the roster and the shared monitors, and a Leave Team button.

Change someone's role

The team page lists every member with a Viewer / Editor picker beside them. Change it and it applies immediately; the member gets a "Your role in «team» changed to …" notification.

Two rows have no picker: yours (you can't change your own role) and the owner's, which shows a Team Owner badge instead.

Remove someone

The 🗑 beside a member removes them immediately — no confirmation step — and they get a "You were removed from team «name»" notification. Their access to everything shared with the team ends at once. You cannot remove yourself.

The team's Edit dialog also removes members, as a side effect: the member list in that dialog is authoritative, so deleting an email chip and saving removes that person. Those removals send the same notification.

Leave a team

A member can leave from the team page (Leave Team) or from the team card on the Teams list. You lose access to every monitor shared with the team, and the owner gets a "… left your team" notification.

An owner cannot leave their own team. The attempt is refused with "Team owners cannot leave. Transfer ownership or delete the team." Do one of those two.

Transfer ownership

In the team's Edit dialog → Transfer ownership → pick a member → Transfer. Read the confirmation, because all three consequences are real:

The new owner becomes the owner, with everything on this page that is owner-only.
You stay on the team as an Editor — not removed, but no longer able to invite, remove, change roles, share monitors, edit or delete the team.
The team now counts against the new owner's plan. If they are already at their team limit the transfer is refused, naming the numbers, and they have to upgrade first.

You can only transfer to someone who is already a member — invite and let them accept first.

One consequence worth knowing before you transfer: the team's owner always gets Editor access to every monitor shared with that team, whoever owns those monitors. So after a transfer, the new owner can edit monitors you shared into the team, and you keep whatever access your own Editor membership gives you.

Delete a team

Delete on the team card, or from the team page. Deleting a team:

removes every monitor share pointing at it (the monitors themselves are untouched),
deletes its pending invitations,
and removes every member's access.

Enori refuses to delete a team that an escalation policy still uses, and the refusal names the policies:

This team is used by 2 escalation policies ("Prod pager", "Weekend cover"). Move them to another team or delete them first.

This is deliberate. A policy whose team no longer exists has no defined meaning — every target type resolves against a team that isn't there — so rather than let you create that state and then discover it during an outage, Enori makes it unreachable. Re-point the policies (the policy form lets you change their team) or delete them, then delete the team.

Teams and the audit log

If you own a team and have shared monitors with it, the Audit Log gains a Team activity view: every action any member took on those shared monitors, filterable by who did it.

You only ever see activity on monitors you shared. A member's actions on their own private monitors stay private. And as the Share dialog warns, the history you see on a shared monitor is its whole history, not just the part since it was shared.

Team lifecycle events — create, update, delete, ownership transfer, invite, join, leave, remove, role change — are recorded in the audit log too, under the Team category.

Getting started

A five-minute setup for the common case: you want a colleague to be able to pause and fix a couple of production monitors, and you want the on-call rota to page them.

1. Create the team

Teams → Create Team. Name it after the group, not the purpose — "Platform" ages better than "Prod alerts". Leave the member box empty for now.

2. Invite the people

Open the team → Invite, one address at a time so you can set each role deliberately.

Someone who needs to act on monitors → Editor
Someone who only needs visibility (a manager, a support lead) → Viewer

Remember the cap includes you: on Base, that's two invitations.

Team page → Share a Monitor. Share the ones this group is actually responsible for, not everything — sharing hands over full history, and a short list is easier to reason about later.

4. Wait for them to accept

Pending invitations show on the team page with their expiry. If one shows EMAIL NOT DELIVERED, hit Resend in the Edit dialog rather than waiting.

5. Point your paging at the team

Now that the team exists, Escalation Policies → Create Policy can use it: pick this team, then have level 1 page All team members or an on-call schedule built on it. That is what turns "they can see the monitor" into "they get woken up".

Full setup in the Alerts guide.

FAQ

Can I put someone in a team without giving them access to a monitor?

Yes, and it's common. Membership grants nothing on its own — a team with no shared monitors gives its members nothing to look at. It is still useful, because escalation policies and on-call schedules draw their recipients from the team's membership.

Can a teammate see my other monitors?

No. Only the monitors you explicitly shared with a team they're in. There is no "share everything" switch.

Can a teammate delete my monitor?

No. Deletion is owner-only regardless of role. The most an Editor can do is pause it.

Why can't my Editor acknowledge an incident from the dashboard?

Because incidents belong to the monitor's owner — see Incidents stay with the monitor's owner above. No role changes that. If a colleague needs to take the pager, put them on an escalation policy: the page it sends them carries an Acknowledge link that works, and that is the supported route.

Someone left the company. What do I remove?

Remove them from every team they were in (the 🗑 beside their row), and cancel any pending invitations to their address. That ends their access to your shared monitors immediately. If they owned a team you're in, ask them to transfer it before their account goes away.

I'm at my member limit but I only have two people in the team.

Pending invitations count against the cap. Open the team, look at Pending Invitations, and cancel any that are stale. Each cancellation frees a seat.

Yes. A monitor can be shared with as many of your teams as you like. Someone in more than one of them gets the highest access any of those teams grants.

What happens to shared monitors if I delete the team?

Nothing happens to the monitors. Only the shares are removed, so the former members stop seeing them. Your monitors, their history and their configuration are untouched.

Can a member invite other people?

No. Inviting, removing, changing roles, sharing monitors, editing and deleting are all owner-only. A member's only membership action is to leave.

Do teammates get my Slack alerts?

Not by default. Your alert channels are yours; a shared monitor's alerts go where you sent them. Teammates get in-app notifications and mobile push about shared monitors, and they get paged on their own channels only through an escalation policy or on-call schedule built on the team.

Can I rename a team?

Yes — Edit on the team card or the team page. The name is also used in the invitation email, so renaming after invitations have gone out means the old name is what those emails say.

Reference: limits and bounds

Setting	Value
Teams you can own	Base 2 · Pro 10 · Business unlimited
Members per team (owner included)	Base 3 · Pro 10 · Business 25
Pending invitations	Count against the member cap
Team name	Up to 100 characters
Team description	Up to 500 characters
Roles you can assign	`viewer`, `editor` — nothing else is accepted
Invitation validity	7 days from creation (Resend restarts the 7 days)
Invitation acceptance	Must be signed in as the invited email address
Scopes for API access	`teams:read` / `teams:write` — see Account & Settings

Alerts — escalation policies and on-call schedules, both built on a team
Incidents — what a teammate can and cannot see
Notifications — the bell, and every team event that writes to it
Audit Log — the Team activity view for shared monitors
Account & Settings — your usage against the Teams limit, and API-key scopes
Billing & Subscription — the per-plan team and member allowances

Last updated: 2026-08-18. Feedback or corrections: support@enori.io