Notification Rules Engine
Stop Fighting GitLab Notifications
GitLab's webhook notifications are all-or-nothing. With Pipie's Lua-powered rules, filter by branch, author, status, and 30+ other conditions.
main | CI: Passed | Approvals: 2
security, feature
Sound Familiar?
Questions You Shouldn't Have to Ask
Every day, developers interrupt each other with questions that should have obvious answers.
"Has anyone reviewed my MR yet?"
You submitted it 3 hours ago. Now you're chasing people down on Slack.
"Has the deploy finished?"
Refreshing GitLab every 2 minutes waiting for the pipeline to complete.
"When was that MR merged?"
Digging through GitLab history to find when a feature actually shipped.
"Did the pipeline pass?"
You pushed 20 minutes ago but didn't hear anything. Is that good or bad?
"Who's working on that fix?"
No visibility into what's in progress across your repositories.
"Is the hotfix live yet?"
Stakeholders asking. You don't know. Time to check GitLab again.
With Pipie, you never have to ask.
The right people get notified at the right time. MR ready for review? The reviewer knows. Pipeline failed? On-call knows. Feature merged? The team knows.
GitLab Notifications Are Too Limited
GitLab's built-in Slack integration is all-or-nothing. Here's what you're missing:
GitLab Slack Integration
- Every merge request event to one channel
- No filtering by branch or author
- Separate config per project
- Can't route different events to different channels
Pipie Rules Engine
- Lua conditions with 30+ variables
- Filter by branch, author, status, and more
- Global rules across all repositories
- Route events to the right channel automatically
Try It Now
Write Rules in Plain Lua
Type mr.
or pipeline.
to see autocomplete suggestions
This rule notifies when a non-draft MR is ready to merge into main with passing CI
Example Conditions
mr.target_branch == "main" and not mr.draft and mr.build_status == "success"
Notify when MR passes CI and is ready to merge to main
pipeline.status == "failed" and pipeline.ref == "main"
Alert when production branch pipeline fails
mr.status == "open" and mr.comment_review_status == "pending" and mr.approvals == 0
Notify when MR needs its first review
mr.provider == "gitlab" and mr.repository.name == "acme/auth-service"
Filter to specific GitLab repository
GitLab vs Pipie: Feature Comparison
See what you're missing with native GitLab notifications
| Feature | GitLab Native | Pipie |
|---|---|---|
| Custom conditions | Basic event types only | Lua expressions with 30+ variables |
| Channel routing | One channel per webhook | Route by condition |
| Filter by branch | ❌ No | ✅ mr.target_branch == "main" |
| Filter by author | ❌ No | ✅ mr.author == "alice" |
| Filter by CI status | ❌ No | ✅ mr.build_status == "success" |
| Global rules | ❌ Per-project only | ✅ Span all repositories |
| Duplicate prevention | ❌ No | ✅ Fire-once per entity |
Powerful Features
Everything You Need for Smart Notifications
Lua Conditions
Write expressive conditions like
mr.target_branch == "main"
30+ Variables
Access branch, author, status, approvals, repository info, and more
Multi-Platform
Same rules work for both GitLab and GitHub repositories
Dynamic Routing
Use Lua to route events to different channels based on branch, author, or status
Global Rules
One rule applies to all repositories - no per-project config
Fire-Once
No duplicate notifications - each MR/pipeline only triggers once
Real-World Use Cases
See how teams use notification rules to stay focused
Release Channel
Notify #releases when MRs merge to main with passing CI
mr.target_branch == "main" and mr.status == "merged"
On-Call Alerts
Alert #oncall when production pipelines fail
pipeline.status == "failed" and pipeline.ref == "main"
Review Requests
Ping #code-review when MRs need their first review
mr.status == "open" and mr.approvals == 0 and not mr.draft
Security Team
Alert #security for specific repository changes
mr.repository.name == "acme/auth-service"
Dynamic Channel Routing with Lua
Route notifications to different channels based on event data. Use Lua expressions to compute the destination channel at runtime.
- Route by target branch (main → #releases, develop → #dev)
- Route by pipeline status (failed → #oncall, success → #builds)
-
Route to team channels by author (
#team-$author)
Route by branch:
mr.target_branch == "main" and "#prod-alerts" or "#dev-alerts"
Route by pipeline status:
pipeline.status == "failed" and "#oncall" or "#builds"
Pipeline Alerts
Know When Things Break
Get notified immediately when pipelines fail on important branches. Route critical failures to dedicated channels so on-call engineers respond faster.
pipeline.status == "failed" and pipeline.ref == "main"
main
📦 Project: acme/auth-service
🔗 <https://gitlab.com/acme/auth-service/-/pipelines/12345|View Pipeline>
Ready to Fix Your GitLab Notifications?
Stop fighting with GitLab's limited webhook settings. Start getting the notifications you actually need.
Pricing
Pricing that grows with you
Choose an affordable plan that's packed with the best features for streamlining your GitLab workflow.
Pro Plan
Perfect for growing teams that need smart notifications and reviewer matching.
$30 /month
Start Trial- Up to 15 contributors
- Merge request tracking
- Pipeline notifications
- $1.50 per extra contributor
Business Plus Plan
Advanced features for large teams with complex workflows and compliance needs.
$150 /month
Start Trial- Up to 100 contributors
- Priority support
- Merge request tracking
- Pipeline notifications
- Team collaboration tools
- $1 per extra contributor
Self-Hosted
Deploy on your own infrastructure with complete data control.
Custom
Contact Us- Deploy on your servers
- Complete data sovereignty
- Custom SLAs available
- Unlimited contributors
Explore More Pipie Features
Discover the complete CI/CD observability platform