Notification Rules
Notification rules decide who is told when something happens to a resource in your project. A rule names a resource type, the events you care about, who to notify, and which channels to use.
Go to Alerting → Rules in the left navigation — the Rules tab sits beside Notifications on the Alerting page. Creating and editing rules requires the Project Admin role.
What a rule contains
| Part | What it does |
|---|---|
| Resource Type | Which kind of resource the rule watches — Jobs, Flows, Table Services, Clusters, Tables or the project itself |
| Scope | Every resource of that type, or a specific list you choose |
| Conditions | Which events fire the rule — for example a Job's run states, or a Flow being created, paused or failing |
| Recipients | Project Admins, the person who created the resource, and/or specific email addresses |
| Channels | Email, the in-app feed, and Slack |
Scope
Jobs, Flows, Table Services and Clusters can be scoped either to all resources of that type or to named ones — useful when one team owns a handful of production Flows and wants alerts only for those. Table and project-level rules apply to the whole project.
A rule scoped to specific resources keeps working as those resources change, but it does not pick up newly created ones. Use an "all" rule if you want new resources covered automatically.
Recipients
- Project Admins — everyone holding the Project Admin role.
- The person who created the resource — for example "The person who created the Job". Available for Jobs, Flows, Table Services and Clusters.
- Specific addresses — one or more addresses you type in, such as a team distribution list or an on-call alias.
You can combine them. A rule that notifies the creator and a distribution list sends to both.
If a rule's only recipient is the resource creator, some resources may have no recorded creator — for example Flows that were discovered automatically, or a Table Service that inherits the creator of the Table it runs on. Those events match the rule but reach nobody. The rule builder warns you when a rule is in this state; add Project Admins or a specific address as a fallback.
Channels
- In-app feed — always on. Every notification appears in the feed regardless of the rule's channels.
- Email — opt-in per rule.
- Slack — opt-in per rule, and only selectable once the project has a Slack integration connected. Without one, the option is disabled and the rule builder tells you why.
Default rules
Every project starts with a set of default rules — Job failures, Flow failures, Flow lifecycle events, Table Service failures, Cluster failures and others — all routed to Project Admins. They are marked Default in the list.
You can disable a default rule or change its recipients and channels like any other. A small number are marked as managed by Onehouse: those keep platform alerts routed correctly and are shown for visibility, but their routing cannot be changed.
If no enabled rule emails anyone about failures, the page shows a banner saying so. Failures still appear in the in-app feed and on the resource page, but no email is sent.
How rules interact with the project Notifications Email
If a Notifications Email is set for the project, it replaces the recipients of every rule for the email channel. The address you configured receives the email, and the rule's Project Admins, resource creator and specific addresses do not.
This is deliberate — it is how a project routes all email to one shared inbox. But it means the two features are not additive:
| Notifications Email | Who receives rule emails |
|---|---|
| Not set | Exactly the recipients named on each rule |
| Set | Only the configured address |
If you want a rule's recipients to apply — say, the Job's creator plus a distribution list — leave the project Notifications Email empty and put the distribution list in the rule's Specific addresses instead. That gives the same reach with per-rule control.
Slack and the in-app feed are unaffected by the Notifications Email.
See Notifications → Email Recipients.
Examples
Only the on-call list should hear about Flow failures.
Resource Type Flows, scope All Flows, condition Failed, recipients Specific addresses → your on-call alias, channels Email. Then disable or edit the default "Flow failures → Project Admins" rule so admins stop receiving it too.
The person who created a Job should know when it fails, and the platform team always.
Resource Type Jobs, scope All Jobs, condition Failed, recipients The person who created the Job and Specific addresses → platform team list.
Alert on two production Flows only, in Slack.
Resource Type Flows, scope those two Flows, conditions Failed and Delayed, channel Slack (requires the Slack integration).
Troubleshooting
A rule exists but nobody is being emailed. Check whether a project Notifications Email is set — it replaces rule recipients for email. See the warning above.
Nobody is notified for a creator-only rule. The resource may have no recorded creator. Add Project Admins or a specific address as a fallback.
The Slack channel is greyed out. The project has no Slack integration connected, or it is still loading. Connect one under external integrations.
A rule cannot be edited. It is managed by Onehouse. Create your own rule alongside it, and disable the default if you do not want both.