My first incident.io-incident happened in my second week here, when I screwed up the process for requesting extra Slack permissions, which made it impossible to install our app for a few minutes. This was a bit embarrassing, but also simple to resolve for someone more familiar with the process, and declaring an incident meant we got there in just a few minutes. Declaring the first incident when you start a new job can be intimidating, but it really shouldn’t be.

We believe incident.io should be used across an organisation, from SRE teams to Customer Success and People Ops. Until now, the way you set up your incident response flows has relied on having one set of roles and fields for every incident, meaning you have to choose between having lots of irrelevant fields to cover every use-case, or not getting the full incident.io experience on some incidents. That’s changing today with incident types, conditional fields and roles!

Responding to and managing incidents feels fairly straightforward when you’re in a small team. As your team grows, it becomes harder to figure out the ownership of your services, especially during critical times. In those moments, you need everyone to know exactly what their role is in order to recover fast. Moving to incident.io as the 7th engineer, from a scaleup of around 70 engineers, has given me a new perspective on what it means to own your code.

We’re building incident.io as the single place you turn to when things go wrong. When an issue is disrupting your business-as-usual, the last thing you want is to start opening ten different tools to diagnose and fix it! As your central incident hub, we need to give you two powers: Workflows cover the former. Workflows are like a mini incident.io Zapier.

At incident.io, we pride ourselves on providing a great product to our customers. We’re also a small team, so we move fast and (whisper it not) occasionally break things. To mitigate the impact on our customers, we have our app set up so that every time our application raises an error (via Sentry), we get paged.

Here at incident.io, we provide a Slack-based incident response tool. The product is powered by a monolithic Go backend service, serving an API that powers Slack interactions, serves an API for our web dashboard, and runs background jobs that help run our customers incidents. Incidents are high-stakes, and we want to know when something has gone wrong. One of the tools we use is Sentry, which is where our Go backend send its errors.

When building an incident response process, it’s easy to get overwhelmed by all the moving parts. Less is more: focus first on building solid foundations that you can develop over time. Here are three things we think form a key part of a strong process. I’d recommend taking these one at a time, introducing incident response throughout your organisation. Just being honest: we’re a startup selling incident management software.

As an early stage company, one of our biggest priorities is hiring. In fact, we have two company goals this year and one of them is.

For the vast majority of organisations, it’s necessary to have some form of round the clock cover to support the business. Whilst it’s most commonly a concern for engineering, it’s increasingly common to have folks from various disciplines available out-of-hours. Irrespective of role, compensating people fairly is an important factor of running a healthy and effective on-call system.

I joined incident.io recently to lead Sales, after having set up my own company. In both startups, one of the first questions I’ve landed on was: “What sales tools should we use as we scale?”. In this post, I’ll walk through our sales stack, and by extension, what I think most B2B SaaS startups can get away using when they have less than ~100 employees.