Stop being interrupted by alerts - let a robot pig send you only what’s important.
It’s the IFTTT of alerts, designed for small software teams.
With Ropig, you can:
- SMS me if BugSnag explodes and sends more than 10 errors in a minute
- Email me if Pingdom sends an alert that my blog server is down, but SMS everyone if it’s the app server
- Email the DevOps team if Librato sends an alert that my Redis server is at 80% capacity, but SMS the team if it’s at 95%
- Post to the #dev Slack channel if New Relic sends an alert that 98% page response time is above 200ms, and SMS teammates who are on-call if it’s above 5 seconds
. . . And STOP telling me about everything else!
What problems does Ropig solve?
Problem: You waste way too much time reading and being interrupted by alerts.
Most noisy alerts happen because you’re monitoring something unnecessarily or because you’ve set the wrong threshold.
Other services don’t let you adjust what is being monitored or set the threshold for the alert, so it’s impossible to fine-tune what alerts the user receives.
How Ropig drastically reduces time spent on alerts:
Event-level routing via JSON field matching
With event level routing you can choose which escalation policy to use based on the event’s properties. For example: a critical event gets sent to the on-call person via SMS, while a warning-level event is sent via email.
We do this with key/value matching on the event’s JSON fields.
Event-level routing allows you to:
- Send alerts to the right person. (e.g. send database related events to the database admin). This helps with noisy alerts since the alert only gets sent to the person who can take an action.
- Send events to the right channel (e.g. for some events SMS me, for others just email me). This helps reduce the number of wake me up in the middle of night alerts.
- Ignore alerts that aren’t important at all. This helps with noisy alerts since you can filter out alerts based on some threshold.
With rate conditioning you’ll only receive an alert if enough events to match the filter have occurred. Rate conditioning is useful for errors where frequency matters. Sometimes you don’t care if one request fails, but 1,000 fails within an hour would be critically important.
Problem: You’re missing important information due to a poor ratio of signal versus noise.
This is what happens when alert maintenance becomes alert avoidance. You’re so snowed under by the firehose of alerts that you only pay attention to the glaring red flags – and in the process you miss all of the smaller problems and warning signs of larger problems to come.
How Ropig keeps you from missing important early warning signals:
Easy setup flow
Less-than-useful alert monitoring is usually due to bad set up. And bad set up is inevitable when tools are needlessly complex and cumbersome. We’ve created a super-simple set up flow without endless configuration options. We believe in a balance of simplicity and flexibility.
Event Batching (coming soon)
Most tools send you events when they happen. Instead, Ropig has the ability to batch them up and sends a whole day’s worth of events in one email. This is useful for stopping non-critical alerts from interrupting your workflow.
Automatic ticket creation (coming soon)
When an event happens, Ropig can automatically create a ticket in Jira, Trello or Github issues. This is an area where we function less like a typical alert management tool and more like IFTTT for alerts – data in, data out, you choose where it goes.
If there’s a webhook, it works with Ropig. We integrate with any monitoring service that can send webhooks. (Hint: that’s basically all of ‘em.) Here are a few of the tools that are most popular with our customers:
- New Relic
- Apex Ping
Ropig routes to:
Frequently Asked Questions
Yup, this one gets asked so much that we’re sticking it right on our homepage.
In trello vs Jira, we’re the trello.
We’re a small team who loves beautiful UI over endless features, speed over bloat, and personal support from engineers over enterprise sales reps.
PagerDuty was created to solve the problem of on-call, but you don’t just need to deal with alerts in the middle of the night. Ropig is a day in and day out solution for alerts.
Our event-level routing is another major difference in how we handle alerts. With event level routing you can choose which escalation policy to use based on the event’s properties. For example: a critical event gets sent to the on-call person via SMS, while a warning-level event is sent via email. Check out a trial – you’ll see that Ropig is a very different experience.
Most monitoring tools offer the option to post to an http endpoint (webhook) when an alert is raised; Ropig is that endpoint. Setup is as easy as pointing all of your service webhooks at Ropig. Ropig then receives the JSON data from the webhook, and does it’s thing.
Yes! We’re compatible with any service that can send webhooks (hint: that’s almost all of them). Some of our most popular services that people track with Ropig are Pingdom, New Relic, Datadog, and BugSnag. But seriously, you can connect anything that can send a webhook.
We use a “punch in/punch out” on call system. That means to be on call you actually have to click a button in the tool. This drastically simplifies scheduling.
The next person on the escalation policy gets notified. Once each step of your escalation policy is hit, the alert will stay open until someone acknowledges it
Yes! We have a default escalation policy, or you can create as many custom policies as you like.
Check out our plans page for all these sorts of details (spoiler: the word “unlimited” gets used a lot.)
Yes! No credit card required. Get started on our plans page here. After your trial you can choose to upgrade if you like it. Cancel anytime.
The team that created MeetEdgar (yes, building Ropig was definitely a solve-our-own-problem situation). You can learn more about us here.