incident.io Blog
incident.io · Company blog · on HN since 2021
Engineers at incident.io write about building their incident management product, covering Go backend performance, monolith design, on-call practice and learning from incidents.
What HN saysHN commenters mention it as an incident management tool alongside PagerDuty and FireHydrant, and recommend its engineering blog. Several commenters are employees.
52HN people shared it
14linked it in comments
112stories submitted
1.4Kstory points
3 months agolast shared
2021people per year2026
Most-shared posts
- 1Tracking developer build times to decide if the M3 MacBook is worth upgrading7 people · 692 points · first shared 2023 · 408 comments on HN
- 2Bloom filters: the niche trick behind a 16× faster API6 people · 16 points · first shared 2025 · 1 comments on HN
- 3incident.io – create, resolve and manage incidents directly in Slack5 people · 7 points · first shared 2021 · 1 comments on HN
- 4Learning from Incidents – Formula 13 people · 8 points · first shared 2021 · discussion on HN
- 5Keep the Monolith, but Split the Workloads3 people · 7 points · first shared 2023 · 1 comments on HN
- 6Don't count your incidents, make your incidents count3 people · 5 points · first shared 2021 · discussion on HN
- 7Handling third-party provider outages3 people · 4 points · first shared 2022 · 1 comments on HN
- 8Logs and tracing: not just for production, local development too2 people · 66 points · first shared 2021 · 25 comments on HN
- 9A modern data stack for startups (2022)2 people · 63 points · first shared 2022 · 26 comments on HN
- 10Incidents Are for Everyone2 people · 34 points · first shared 2021 · 13 comments on HN
- 11We turned off Pub/Sub and nobody noticed2 people · 11 points · first shared 2026 · 3 comments on HN
- 12How to get everyone at the company to value writing2 people · 10 points · first shared 2022 · 1 comments on HN
- 13How we built our workflow engine2 people · 5 points · first shared 2022 · 1 comments on HN
- 14The three pillars of great incident response2 people · 4 points · first shared 2022 · 1 comments on HN
- 15Five steps to better customer communication2 people · 4 points · first shared 2021 · discussion on HN
What HN people wrote when they linked it
TimeWeSp · 2023-07-03
I've experienced all these problems. There are solutions trying to address them. E.g. https://incident.io/ (which I'm not affiliated with in any way). It's not easy though. I think they all come from the root cause of teams not investing enough into making oncall processes and solutions good, and in particular not keeping things up-to-date. As you say, runbooks are often outdated. The same happens with lists mapping component ownership to teams.
There's another problem (#8 to add to the list) I also felt pain from: how you're scheduled to work oncall. We had ad-hoc manual scheduling of who would work oncall when. A tool for solving that is https://oncallscheduler.com (which I am affiliated with). It automates the oncall scheduling, while making it fair, predictable, and gives all engineers self-service control over when and how they're scheduled. I'd love some feedback on it.
joaoqalves · 2021-11-09
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 observability solutions
3. Having a status page to put a small description for non-technical stakeholders.
PagerDuty covers some of this. Monzo's Response [1] and now incident.io [2] try to cover it too. I'd like to have this experience end-to-end.
1 - https://github.com/monzo/response
2 - https://incident.io/
shelika · 2025-08-10
Biased as I work for them but I think https://incident.io/blog/engineering is definitely worth adding.
lawrjone · 2025-05-17
I'm one of the engineers at incident.io, so thanks for the mention! But yes, when we first started the majority of our customers bought us for incident management and used PagerDuty as their on-call provider (phones them, receives the alerts, hands-off to us when an incident starts).
We've since built on-call directly into our product and we've had loads of those customers migrate entirely into us, dropping PagerDuty. The biggest customers we're onboarding now tend to buy us as their sole on-call and incident management tool, too.
We have a bunch of case studies of people who've moved if that's useful to anyone. My favourite is probably Intercom who migrated from PagerDuty into our on-call in a few weeks (the Intercom team are great fun to work with!)
https://incident.io/customers/intercom
AYBABTME · 2023-06-29
There's some nice tooling these days for this. E.g. https://firehydrant.com/ and https://incident.io both make this a faster, more embedded process.
arussellsaw · 2022-07-11
Author here, this post was a fun little write up of some of the work we've been doing here over the last month, it felt like a really nice self contained recipe that others could play with easily, so wanted to share!
It's worth saying that this setup is double handy when you add in our local environment tracing setup we talked about here: https://incident.io/blog/tracing
jen729w · 2022-06-18
> At incident.io, our engineering team runs on-call Friday-to-Friday, with a 5pm handover. This works great for us: as an engineer coming off the pager you get to finish work nice and early on a Friday and enjoy your evening. [0]
[0]: https://incident.io/guide/on-call/compassionate-on-call/
Is this an American thing? 5pm is not “nice and early on a Friday”! 4pm is about what time you should be finishing, and 3pm is “nice and early”.
Love, Australia x
zeroCalories · 2025-02-10
I think the main problem is that measuring a lot of these things is incredibly hard. The post mentioned laptops and build time and it reminded me of a blog post[1] trying to figure out if it's worth upgrading to m3 macbooks. I encorage you to read the post yourself, but my impression is that the whole project was a huge waste of time. I suspect most attempts to measure impact will end this way. I also think a lot of the recomendations on fighting frupidity are seriously flawd. For example letting developers decide isn't any garentee that you've made the right choice, but it is a garentee that you've made an expensive one. Unless the developers are basically paying for their own tools like in a startup, this is definetly a way to piss away a companiese funds on developers that are more concerend with their own career than the profitibility of the company.
[1] https://incident.io/blog/festive-macbooks
alberth · 2023-12-30
Interesting Pricing strategy (for Incident.io)
Plan A: $16 (month/user)
Plan B: $10,000+ Call Us
Plan C: Call Us
Those are some of the steepest price cliffs I’ve ever come across.
https://incident.io/pricing#plan-comparison
mixmastamyk · 2023-12-29
A lot of the graphs near the end comparing side-to-side had different scales on the Y axis. Take results with a grain of salt.
https://incident.io/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimag…
rajeshrajappan · 2022-09-19
Building Workflows, Part 2 – the executor and evaluation
https://incident.io/blog/building-workflows-part-2
evnsio · 2022-06-18
This is something we spoke about in https://incident.io/blog/on-call-at-incident-io. Specifically:
> On-call payment is not expected to cover any time you spend working outside of hours. If you're paged and end up working in your evening, you should take time off in lieu. We trust you to manage this time yourself.
I'll make sure this is added this to the guide. Thanks for the nudge!
alexeldeib · 2025-10-15
pbronez · 2025-08-10
Cool idea. I thought I’d try to make a Kagi Lens to accomplish the same thing:
https://kagi.com/lenses/LdYine8hZtYmrt8yTMngOUtvTM9rmkRy
Kagi Lenses can be defined in many ways, one of which is specifying URLs to search. Unfortunately you can only provide 10 URLs per lens. Here are the ones I chose:
https://stripe.com/blog/engineering, https://engineering.fb.com/, https://www.uber.com/en-US/blog/engineering/, https://netflixtechblog.com/, https://research.google/blog/, https://technology.riotgames.com/, https://incident.io/blog, https://www.anthropic.com/engineering, https://openai.com/news/, https://shopify.engineering/