Thank you for the feedback, we'll make some changes to the page.
Agree on those companies having technical talent and in fact a vast majority of our customers came to us with their own bot built out that resembles of our features. It really comes down to the age old question, build vs buy? The maintenance cost and feature enhancements for something owned in-house can be burdensome but I am obviously bias towards it.
We've seen it takes usually at least an engineer one whole quarter to standup the basics of nailing creating incidents right with some basic automation.
But the times customers decide building it themselves isn't worth it is often a) someone that owned it had left the company and b) its a big distraction from their core focus/ has become a full-time job to maintain.
This was an awesome response and you absolutely nailed it.
A vast majority of our customers actually have some sort of internal bot built. It's quite limited usually and largely focused on the "creation" portions of an incident. Most commonly create an incident channel, create Zoom, link to a few integrations, and that seems to be it.
But depending on who you speak with that can be enough which is totally fair. Especially when complexity and incident volumes are low.
And yes agree not every user on the platform will value it the same. An SRE vs. someone in legal will find different value out of it. Our goal is to make this accessible to the entire org not just engineering teams.
Thank you for the feedback on the pricing page as well!
If you email [email protected] we can get you some pricing ASAP. It'll be dependent on number of users and level of support/onboarding/custom feature development required.
But if you're a small team, Rootly is powerful and ready to go out of the box with defaults and you might not require some of the custom stuff.
To answer your question directly, we customize each package for each individual customer on a bunch of variables.
From our experience we still see them in a number of deals. I think their focus has shifted more towards SLOs and Microsoft Teams though, areas where we aren't investing in right now.
We have seen Slack start investing in this area with their own Workflow Builder they announced last year. One of the big use cases they highlighted was incident response. We haven't ran into any customers trying to leverage that just yet though as still a lot of heavy lifting required.
IMO what makes Slack so power is their app ecosystem. We aren't too worried about them shutting that down or competing with us. We see the awesome folks on the Slack Platform team continue to invest heavily there.
But if Slack wants to seriously compete in this space we'd welcome it. The more attention and competition the better. Most accounts we approach we've found they didn't know off the shelf solutions existed!
That is spot on. We're investing in our Web platform which has the exact same experience and quite a few companies running incidents from there.
But the Slack ecosystem has been great for us so far. Easy to develop on and fairly flexible in terms of what we can do. I think the most challenging part is going through the review cycle, can take longer than expected when you're constantly shipping new features!
Although this post is largely focused on our integration with Slack, we have a standalone Web platform that does the exact same. We have quite a few companies (especially MS Teams shops) run incidents solely from there.
This also serves as a backup when Slack goes down, users can continue using Rootly (top 5 most common questions we get).
Sorry to hear that. I'll do my best to resist asking if you'd like to chat instead ;).
We try to take a very "partnership" centric approach. What that looks like day-to-day is our engineers/success/leadership team collaborating in a shared Slack Connect channel on new features. For a lot of our customers we get deep into the problem and bring in outside speakers from the industry to come do workshops, AMAs, etc. that might align well with the challenges.
Incident.io is likely our closest competitor and are doing amazing work over there. They have a strong team and smart founders that have been in the trenches before. From a product perspective they are my favourite of our competitors if I had to pick one myself to use.
Our differences are largely driven by the customer segment we serve and the needs of SMB vs. enterprise. We've found by going upmarket to enterprises such as Canva, Shell, Bolt, it is quite difficult to develop an opinionated platform based on only industry best practices as each organizations approach to incidents (regardless if it's the same tooling) vary greatly in their process. You'll find Rootly to be a lot more pluggable, customizable, and can turn any knob the make the product work for you if needed. The reason for this is because we find change is hard, even small process tweaks in process. We want to reduce as much of that as possible when a new tool is brought in.
We tried to think of our pricing as the value a user would get out of the tool. The amount of time and headache we'd save them when actually responding to an incident. We've found a lot more pushback for smaller sized companies (e.g. <20 eng) but have also realized the challenges of managing incidents are less pronounced.
Just curious for my own learning, is the thinking behind "should be cheap" motivated by potentially not everyone would need access to tools in monitoring, alerting, response?
So glad you asked. Once the incident is in a resolved, we'll prompt you to edit your postmortem. This can be done inside of Rootly but most commonly we'll auto-generate a Confluence or Google Doc. Here you'll have all your incident metadata, template to fill out, but most importantly your incident timeline (no copy-paste required).
From there we can help you do things like automatically scheduling your postmortem meeting with everyone that was involved.
We also want to help you improve your process and response. We'll prompt anyone involved in the incident for feedback (they can submit anonymously too) and collect important metrics.
There are top line metrics like incident count, MTTX, outstanding action items but also finer grained ones which is what I think you might be hinting at. For example you can visualize automatically what services are being impacted the most. That might be an indicator as an area to focus on more.
We try to keep the garden walls on the product quite low, allowing you to export any of the data out of Rootly and into your own analytics engines.
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, etc). We do this to hopefully reduce the amount of change required when a new tool is brought in. As a result we focus on features such as our Workflows engine that allows for this customization. Another big area of focus for us is unsurprisingly Slack, we think of the other areas of Rootly such as our Web platform to be the backend that powers this.
FH does a lot of things well and has great customers too. They have a sleek UI, strong security posture, and more. Their approach is more opinionated in guiding you through incident best practices. There is no wrong answer here as we hear plenty from customers that want both.
This is also true with silences. When we switched from analogue phone calls to digital phone calls in the 90's, SIP began to ingest white noise during silences due to discomfort perceived by the users thinking they got hung up or the network has been disconnected.
Agree on those companies having technical talent and in fact a vast majority of our customers came to us with their own bot built out that resembles of our features. It really comes down to the age old question, build vs buy? The maintenance cost and feature enhancements for something owned in-house can be burdensome but I am obviously bias towards it.
We've seen it takes usually at least an engineer one whole quarter to standup the basics of nailing creating incidents right with some basic automation.
But the times customers decide building it themselves isn't worth it is often a) someone that owned it had left the company and b) its a big distraction from their core focus/ has become a full-time job to maintain.