Hey, incident.io CEO here. I'm sorry to hear that. Can you explain a little bit more?
353 karma · joined April 28, 2014
There's truth to this: as with all new product categories, there's some education that needs to go along with the sale, and budget that needs to be found, that doesn't currently exist. On the whole, we haven't found this to be a large challenge so far. Most people look at our product, see a very fair exchange of value, and are happy to pay.
However, that isn't why we built On-call. We built it - along with many other reasons - because it's part of the trifecta that we think you need to do incident response well:
1. A way to alert people that something is wrong 2. A way for them to respond, resolve and learn from the incident 3. A way for them to communicate to their customers about it
We have built all of these respectively in On-call, Response and Status Pages. Consolidating all of these into one cohesive product makes obvious sense, to us at least. We'll see what the market says!
We've made a few deliberate tradeoffs here in terms of sharing questions, and the process up front with candidates. It's worked well so far, but we'll see how it goes.
Feel free to sign up for a free trial, no credit card required at incident.io
Thanks very much, I appreciate the kind words. Right now, we're in early access where we're partnering with companies for feedback on the product so we can make something that people love.
As such, our pricing is pretty simple — we charge based on the number of Slack users in your workspace, and put you in a bucket. For some companies, that doesn't work as well (e.g. if 95% of your company is customer support agents that would never use the tool), and we change it as appropriate. Basically, we'd rather optimise for feedback and love than for revenue at this point :)
> I'm hoping the success of incident.io at GC can extend to the ops teams over time
I hope so too. Let us know anything that you think might make that easier.
Yes, and no. Almost all of our customers already use PagerDuty, with Opsgenie a distinct second. They predominantly use them to wake people up when things go wrong, but don't use them to actually _run_ their incidents.
I think there's a variety of reasons for this from it not being easy to imprint your process onto PagerDuty, to it being harder to use for non-technical folks, and it not being where you communicate with the rest of your organisation (often Slack).
The most common competitors we come up against are:
1. Your process being written down on a piece of paper, which humans then remember to follow (spoiler: it's hard to do this) 2. In-house tooling that folks have built to help fix this problem. Many scale-ups have built their own (Stripe, Monzo, Robinhood, Transferwise, Influx Data, etc).
We take people from thing went wrong, to response, to debriefing, to following up on actions afterwards. Right now, we don't wake people up through alerting, but it's a natural next step for us to go and do that as well.
I touch on the sorts of topics I'll be covering in the introduction of the post. Roughly, it'll be a blend between operating more effectively (e.g. better estimating work, taming Slack), and more technical posts (effectively testing in production, etc)
Would love to hear feedback and thoughts.
On sync.Pool: good spot. I'll update it - thanks.