Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Rootly (YC S21) – Manage Incidents in Slack

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 96 posts

Re: Launch HN: Rootly (YC S21) – Manage Incidents in Slack

#51

Post by tnolet »

kwent wrote: post #6
rgthelen wrote: post #4

Congrats on the launch. How is this different than FireHydrant?

Thank you! Great question, There are quite a few differences, namely in our product design focus. We've taken a more configurable and flexible approach that focuses on plugging into a companies existing stack and their process. Often times we'll have customers send us their entire playbook on what they have now and ask us to automate that as a starting point (e.g. rename Slack channels to my Jira number for incidents…

Why did you or your team copy & paste the FyreHydrant docs?

Re: Launch HN: Rootly (YC S21) – Manage Incidents in Slack

#52

Post by kc10 »

Congratulations on your launch!

The incident response space is brutally competitive and there are so many players all providing the same functionality.

I think the main problem you would have with your customers is their inertia. If an enterprise has their tools and processes setup, even though you provide a better tool at a lower price point, it's not worth their time switching to a new provider if whatever they have is working just fine.

Re: Launch HN: Rootly (YC S21) – Manage Incidents in Slack

#53

Post by jjtang1 »

kc10 wrote: post #52

Congratulations on your launch! The incident response space is brutally competitive and there are so many players all providing the same functionality. I think the main problem you would have with your customers is their inertia. If an enterprise has their tools and processes setup, even though you provide a better tool at a lower price point, it's not worth their time switching to a new provider if whatever they hav…

Thank you!

And yes the space is heating up for sure. Really good awareness and attention developing as a result though. We are also noticing monitoring companies starting to snag up companies to developing into this space (e.g. Datadog https://www.datadoghq.com/blog/incident-response-with-datado...). But by far our fiercest competition are companies that are still building a subset of what we have internally. Depending on complexity and incident volume we've seen many cases where it's good enough like you mentioned.

Inertia and change management is the #1 barrier to adoption. Companies have ways of workings (right or wrong) that are engrained and established. To come in and rip it all up and say "this is the right way to manage incidents" is a tough pill to swallow. Even the inability to manage IaC or integrate with a specific tool can cause quite a bit of friction. The technical setup of any of these tools is quite easy, the real home run is how does that tool help you drive adoption?

Re: Launch HN: Rootly (YC S21) – Manage Incidents in Slack

#55

Post by jjtang1 »

renewiltord wrote: post #54

Took a quick look at your loom. Very cool. In practice, we prefer just looking through a single channel with threads, but perhaps that's because we're a small team.

Thank you!

You're not alone, I've ran into quite a few cases where working from a thread will suffice (big and small companies). We are still team dedicated incident channel but there are a few things that threads do better.

For example, the number of incident channels that get spun up can get out of hand. Threads are a lot cleaner for that. So we built a workflow that'll let you specify an auto archive behaviour.

We also don't want you to lose context of your threads or conversations, you can run /incident convert in Slack and we'll pull that context over. Lastly, we often see people working from threads from a primary #incidents or #outage channel for better visibility. We'll actually let you specify exactly who you want to notify whenever an incident gets opened/closed.

But generally we found we can do a lot more powerful things in dedicated channels around integrations or even assigning roles if that is important :)

Happy to chat more on your use case tho!

Re: Launch HN: Rootly (YC S21) – Manage Incidents in Slack

#56

Post by cortesoft »

hijinks wrote: post #35
dneri wrote: post #32

Congrats on the launch, I would use this for my smaller team. Why have a pricing page with no pricing on it though?

because they want to look at crunchbase and find out how much funding you got then charge you based off that. I wish companies would boycott companies doing contact us for pricing

> I wish companies would boycott companies doing contact us for pricing

A lot of companies do, by simply never contacting them for pricing.

Re: Launch HN: Rootly (YC S21) – Manage Incidents in Slack

#57

Post by drevil-v2 »

I will echo the other comments on no upfront pricing. Even though this could be potentially useful for my team, I won't "contact" you for pricing. I am sick of having to deal with salespeople who want to know a ton of info about your business so they can gouge every last cent out of you and then some.

I would gladly pay a little extra just to have clear pricing and sign up with a credit card. I have got an engineering org to run, don't have time to moonlight as a procurement officer.

Re: Launch HN: Rootly (YC S21) – Manage Incidents in Slack

#58

Post by turtlebits »

Watching the demo, how is this more than a glorified Slack workflow to a generic ticketing system? The only additions I can see are lifecycle events that update your ticket and the postmortem reminder?

This could be easily done with an engineer/tech following a runbook/doc that's linked in the alert. Cutting tickets, creating a slack channel, escalating, and/or setting up a bridge can be done in minutes (and most alerting systems can automate that).

IME, defining the and enforcing the process is more important than the automation.

Re: Launch HN: Rootly (YC S21) – Manage Incidents in Slack

#59

Post by renewiltord »

jjtang1 wrote: post #55
renewiltord wrote: post #54

Took a quick look at your loom. Very cool. In practice, we prefer just looking through a single channel with threads, but perhaps that's because we're a small team.

Thank you! You're not alone, I've ran into quite a few cases where working from a thread will suffice (big and small companies). We are still team dedicated incident channel but there are a few things that threads do better. For example, the number of incident channels that get spun up can get out of hand. Threads are a lot cleaner for that. So we built a workflow that'll let you specify an auto archive behaviour. We…

Great stuff. Good luck with your product. I imagine we'll need it later but for the moment, I think we're too small to be worth your time.

Would have loved to have run into you guys when/if you were looking for seed investment though

Re: Launch HN: Rootly (YC S21) – Manage Incidents in Slack

#60

Post by jjtang1 »

turtlebits wrote: post #58

Watching the demo, how is this more than a glorified Slack workflow to a generic ticketing system? The only additions I can see are lifecycle events that update your ticket and the postmortem reminder? This could be easily done with an engineer/tech following a runbook/doc that's linked in the alert. Cutting tickets, creating a slack channel, escalating, and/or setting up a bridge can be done in minutes (and most ale…

Appreciate the feedback!

You could certainly go through a checklist/runbook that got attached to the incident. This is usually the setup most companies we speak with have. However, compliance, consistency, and speed on following that during a stressful incident tends to be quite poor. Tasks like creating Slack channels, Zoom bridge, I agree aren't difficult but not things expensive engineers should be focused on. We want them to focus on putting out the fire and not the admin.

A few things for example a simple doc won't be able to accomplish:

- automatically track incident metrics

- set recurring reminders to e.g. update the statuspage

- auto-archive channels after periods of inactivity

- create incident timeline without copy-pasting

- update Jira/Asana/Linear tickets with incident metadata and action items

- automatically invite responders to the incident channel

None of which are impossible to do manually, just a question of how much time you'd like peoples spending on it. If you have a few incidents a year I agree this is likely overkill.

Post reply on HN