Live data from Hacker News

Grafana OnCall: an easy-to-use on-call management tool

grafana.com

31–40 of 75 posts

Re: Grafana OnCall: an easy-to-use on-call management tool

#31
post #17

> Alerts from each integration 300 5 minutes > Alerts from the whole team 500 5 minutes > API requests per API key 300 5 minutes Product looks great but those API request limits are too low, because alerts rain when you are having incidents and rate limiting all of them is harmful. That's why other products have deduplication keys / aliases so you don't miss important ones. https://grafana.com/docs/grafana-cloud/onca…

That's why other products have deduplication keys / aliases so you don't miss important ones.

Care to link to the docs? I'm interested.

Re: Grafana OnCall: an easy-to-use on-call management tool

#32
post #14

Hey everyone, Matvey, ex-CEO of Amixr is here. Me and Ildar Iskhakov started this project three years ago because we used to be on-call ourselves and needed better tools. It was an amazing journey from 0 to 1. Tons of coding, first customers, fundraising, iterating, and finally the honor to join Grafana Labs and build Grafana OnCall! I'll be happy to answer your questions if you have any.

It's great to see more competition in this space. Generally speaking, what I miss in these "incident management" products is also an integrated, flawless way to handle incidents when they're happening. I'm talking about: 1. Quickly creating a proper chat 2. Quickly creating an incident document where you can pin chat messages and use it in the post-mortem. Ideally, pinning some graphs that you'd extract from your obs…

Monzo's solution does not seem to be actively maintained, is it?

+100 on the creation of incident chat rooms and pinning data to re-use in incident docs. There is nothing worse than copying the timeline events from one tool to a Google Doc.

Re: Grafana OnCall: an easy-to-use on-call management tool

#33
post #32

Earlier quoted context omitted.

It's great to see more competition in this space. Generally speaking, what I miss in these "incident management" products is also an integrated, flawless way to handle incidents when they're happening. I'm talking about: 1. Quickly creating a proper chat 2. Quickly creating an incident document where you can pin chat messages and use it in the post-mortem. Ideally, pinning some graphs that you'd extract from your obs…

Monzo's solution does not seem to be actively maintained, is it? +100 on the creation of incident chat rooms and pinning data to re-use in incident docs. There is nothing worse than copying the timeline events from one tool to a Google Doc.

AFAIK, the creators created incident.io as a spin-off [1] :) Smart move, I must say.

1 - https://www.indexventures.com/perspectives/incidentio-raises...

Re: Grafana OnCall: an easy-to-use on-call management tool

#34
post #17

> Alerts from each integration 300 5 minutes > Alerts from the whole team 500 5 minutes > API requests per API key 300 5 minutes Product looks great but those API request limits are too low, because alerts rain when you are having incidents and rate limiting all of them is harmful. That's why other products have deduplication keys / aliases so you don't miss important ones. https://grafana.com/docs/grafana-cloud/onca…

That's why other products have deduplication keys / aliases so you don't miss important ones. Care to link to the docs? I'm interested.

https://support.atlassian.com/opsgenie/docs/what-is-alert-de...

https://support.pagerduty.com/docs/event-management

Re: Grafana OnCall: an easy-to-use on-call management tool

#35
post #16

Is there really anybody else in the "Pager" category of SaaS products other than PagerDuty that have any traction?

I work on/for an open source solution that we based off of PagerDuty, called GoAlert: https://github.com/target/goalert

Yep. This is a great product. Has the features you need, is super reliable and easy to manage.

Re: Grafana OnCall: an easy-to-use on-call management tool

#37
post #14

Hey everyone, Matvey, ex-CEO of Amixr is here. Me and Ildar Iskhakov started this project three years ago because we used to be on-call ourselves and needed better tools. It was an amazing journey from 0 to 1. Tons of coding, first customers, fundraising, iterating, and finally the honor to join Grafana Labs and build Grafana OnCall! I'll be happy to answer your questions if you have any.

It's great to see more competition in this space. Generally speaking, what I miss in these "incident management" products is also an integrated, flawless way to handle incidents when they're happening. I'm talking about: 1. Quickly creating a proper chat 2. Quickly creating an incident document where you can pin chat messages and use it in the post-mortem. Ideally, pinning some graphs that you'd extract from your obs…

I use incident.io. Pretty happy with it. Very responsive team.

Re: Grafana OnCall: an easy-to-use on-call management tool

#38

Is there really anybody else in the "Pager" category of SaaS products other than PagerDuty that have any traction?

Also what happens if pagerduty goes down?

Your service(s) going down and pagerduty going fully down is very unlikely to happen. Even if it does, you're probably going to get called by customer support because users never go down;)

Re: Grafana OnCall: an easy-to-use on-call management tool

#39

Is there really anybody else in the "Pager" category of SaaS products other than PagerDuty that have any traction?

PagerTree - https://pagertree.com

My team uses PagerTree. Easy to get started with, has the tools you need without being overcomplicated.

Re: Grafana OnCall: an easy-to-use on-call management tool

#40
post #17

> Alerts from each integration 300 5 minutes > Alerts from the whole team 500 5 minutes > API requests per API key 300 5 minutes Product looks great but those API request limits are too low, because alerts rain when you are having incidents and rate limiting all of them is harmful. That's why other products have deduplication keys / aliases so you don't miss important ones. https://grafana.com/docs/grafana-cloud/onca…

I'd think that receiving even 1/5th the rate limit in a 5 minute window would be disorienting enough to render alerting effectively useless. I'd question the configuration which fires that many alerts in that time frame, and suggest improving alert aggregations and dependencies to get the number down to one or a handful of meaningful alerts.

The overhead of maintaining those configurations all the time is usually too high to be worth it considering the benefit and likelihood of reaping it.

Also, in my experience with those systems, they only make sense to use very sparingly. Your monitoring becomes extremely fragile when your aggregations and dependencies get complicated enough that "what will our alerting system do when X happens?" results in a flow chart with 18 steps.

If you aren't careful, you can end up making your aggregations less useful than the raw alerts would be.

Post reply on HN