Your infrastructure generates a constant stream of events. Workflows complete, drift gets detected, PRs merge, approvals come in. Until now, you had to go looking for that information — checking individual repository Actions tabs, scanning workflow run logs, or waiting for someone to mention it in Slack. There was no single place that told you what happened that matters to you.

That changes today. Atmos Pro now has a notification inbox that surfaces the events you care about, scoped to the work you are actually connected to.

There is a new bell icon in the dashboard header, right next to your profile menu. When something happens that involves you, a badge appears with the count of unread notifications. Click it to open the notification panel.

The panel has two tabs: Inbox and Archive. Inbox shows everything you have not dealt with yet. Archive is for notifications you have acknowledged and moved out of the way. You can mark individual notifications as read, mark all as read, or archive them one by one.

Click any notification to navigate directly to the relevant resource — the workflow run that failed, the instance that drifted, the PR that merged. The goal is to get you from "something happened" to "here is what happened" in one click.

Not every event in your workspace generates a notification. We started with the events that teams told us they most want to know about immediately:

Workflow runs — When a workflow run completes successfully or fails, the committer who triggered it gets notified. Failed runs are the most important signal here. You pushed a change, it went through the pipeline, and something broke. You should know about that before someone files an issue.

Drift detection — When Atmos Pro detects that an instance has drifted from its expected state, all workspace members get notified. Drift is the kind of thing that compounds silently. A resource gets modified through the console, a security group changes, and your Terraform state diverges from reality. The notification makes sure nobody misses it.

Drift remediation — When drift gets remediated, you get confirmation that the state is back in sync. This closes the loop on drift notifications so you know when action has been taken.

Approval requests — When a workflow run requires approval before proceeding, the designated approvers get notified. No more checking GitHub periodically to see if something is waiting for your sign-off.

PR merges — When a pull request that touches your infrastructure gets merged, the PR author gets a notification. This is especially useful in large organizations where merge-to-deploy can take time and you want confirmation that your change landed.

Billing alerts — Payment failures and trial expiration warnings go to workspace administrators. These are the kind of notifications you absolutely cannot miss — a failed payment can lead to service interruption.

Team invitations — When someone gets invited to a workspace, they get a notification. Simple, but it closes the loop on team management.

The most important design decision we made is that notifications are not a firehose. You do not get notified about every event in your workspace. You get notified about events that are connected to you.

The system matches your GitHub identity — the same login you use to authenticate with Atmos Pro — against the committers, authors, and actors on each event. If your colleague pushes a change and their workflow fails, they get the notification. You do not. If you are the one who triggered the drift detection, the results come back to you.

For workspace-wide events like drift detection, all members get notified because drift affects the whole team regardless of who caused it. But for individual workflow runs and PR activity, the targeting is precise. This means your notification inbox stays relevant. It is your activity, your changes, your infrastructure — not noise from the entire organization.

Not every notification type is relevant to every team member. A junior engineer might not need billing alerts. A platform lead might not need notifications about individual PR merges because they are reviewing them anyway.

You can opt out of specific notification types per workspace. The preference system is simple — each notification type can be enabled or disabled independently. By default, everything is on, and you turn off what you do not need.

This is the foundation. The notification system we shipped today handles the in-app experience — the bell, the inbox, the read/archive workflow. But we are already working on what comes next.

Email digests will aggregate your notifications into a daily or weekly summary so you can catch up without logging into the dashboard. Slack forwarding will push critical notifications — like workflow failures and drift detection — directly into your team's channels. Custom notification rules will let you define exactly which events trigger notifications and how they get delivered.

The underlying event infrastructure supports all of this. Every notification is typed, scoped to a workspace, and linked to a source entity. The system knows who should receive what and why. Expanding the delivery channels is a matter of wiring, not rearchitecting.

Start using notifications today. Open Atmos Pro, look for the bell in the top right, and see what happened with the changes you pushed.