Updating notification settings across dozens of individual monitors is a waste of engineering time. If a developer changes their email, you shouldn’t have to edit twenty separate cron configurations.

We built teams to solve this. Teams act as reusable containers for your notification channels, decoupling your alert logic from your monitoring logic. You define the notification group once, and assign it anywhere.

What defines a team?

In olic.io, a “Team” isn’t a permission group for user logins—we built collaboration to solve that—it is a logical group of individual notifications.

Think of a Team as a distribution list. You might create a Team called “Backend Ops” or “Client X Support.” Inside that Team, you can store an unlimited number of notification channels (emails, webhooks, etc.). This allows you to treat a mixed group of people or services as a single entity.

Mixing channels for flexible preferences

You likely have engineers who live in Slack, while others rely on email. You do not need to create separate “Slack” and “Email” groups to accommodate them.

If you have a team of three members—two who prefer Slack and one who prefers Email—you simply create one Team containing those three specific endpoints.

When a monitor assigned to this Team fails, we trigger all three channels simultaneously. Everyone receives the alert on the platform they actually use, without you managing complex routing rules.

Granular assignment and control

Once a Team is created, you can assign it to unlimited monitors. This is a “write once, apply everywhere” workflow.

However, we know flexibility is key. Inside any specific monitor, you can view the assigned Teams and enable or disable notifications for them based on relevance. This allows you to silence a specific distribution list for a non-critical job without deleting the configuration or removing the Team entirely.