5 ms·

Show HN: I am building an open-source incident management platform

168 points by sanj001 2y ago

I'm building Incidental, an open-source (MIT license) incident management platform. I've been working on it for the past couple of months as a hobby, and now it's at a state where I'm comfortable sharing it. This is also my first open source project. Features: - Custom roles - Custom severities - Integrated with Slack - Web interface Todos: - Custom fields - Custom workflows Website: https://incidental.dev https://incidental.dev Github: https://github.com/incidentalhq/incidental https://github.com/incidentalhq/incidental I'd love to hear your feedback. Thanks!

matthewcford 2y ago
We've been building same thing hope to share it soon.
- dotancohen 2y ago
  Tell us more.
otabdeveloper4 2y ago
> Slack Thanks but no thanks.
- shahahmed 2y ago
  curious, is this because you expect something other than Slack supported?
  - otabdeveloper4 2y ago
    Slack is a piece of shit software. Sorry for being blunt. Yes, I will be that guy.
    - SergeAx 2y ago
      What does your team use instead?
- DowagerDave 2y ago
  could be worse... Teams cough, cough
allywilson 2y ago
Different auth options (SAML, OAuth, etc.) would be a nice to have. I look forward to the progress on this tool :-)
novia 2y ago
I love to see it. Thank you for building this. This is a problem that's been solved many times over by private companies, and they charge other institutions exorbitant fees for the privilege of using their software. I hope you can get many companies to put skin in the game and contribute towards fixing bugs. It'll be cheaper for them in the long run than paying those external vendors. For those of you complaining about the slack integration in the comments, you know you can just not connect that, right?
- dewey 2y ago
  > I hope you can get many companies to put skin in the game and contribute towards fixing bugs. It'll be cheaper for them in the long run than paying those external vendors. This would be a nice world to live in, but unfortunately this is very rarely the case as you can see with most open source projects that are used in many companies and are underfunded and understaffed. Most bigger companies value saved time of not integrating something themselves, liability and having someone else to call if something goes wrong higher than saving a few thousand bucks a year for some external vendor. Which makes total sense for something that's not your core business.
- lawrjone 2y ago
  Don't these people already have the option of running open-source tools like Netflix's Dispatch or Monzo's Response? If they have the open-source options why would they pay for the hosted services?
  - rm_-rf_slash 2y ago
    Support, liability protection, SLA…there’s a reason people pay for tools they can get for free.
Rickasaurus 2y ago
My pet feature is good and tight Jira (or ticket manager) integration so it opens tickets for the team to put time on, maybe even syncs time? Really nicely streamline so the time to remediate is tracked as part of the team's work.
vindex10 2y ago
I will just share a somewhat similar project: https://github.com/netflix/dispatch https://github.com/netflix/dispatch Also open source, also Python, also incident management, also custom severities (but not as much of custom roles, afaik) :) Has some integrations with slack, but not focused on Slack particularly. Can be a good project to learn from as well :) My relation to it: I only contributed with a couple of pull requests there :)
- brunoqc 2y ago
  It looks nice. I wish it would support prometheus/lokio/grafana.
- SoftTalker 2y ago
  Best Practical, makers of the venerable "RT" request tracker, also make an IR system based on that technology. https://bestpractical.com/rtir https://bestpractical.com/rtir I haven't used their Incident Response but used the basic RT for years. It's solid and never gave us any trouble. It is all (or mostly) written in Perl however if that is a concern. Open-source and free to run on your own, or you can pay for cloud hosting and support.
synack 2y ago
Use the semantics of the standard Incident Command System. Emergency responders have spent decades figuring out the best way to organize for these situations. Tech orgs should leverage that work. https://en.wikipedia.org/wiki/Incident_Command_System https://en.wikipedia.org/wiki/Incident_Command_System https://training.fema.gov/nims/ https://training.fema.gov/nims/
- joseferben 2y ago
  this looks interesting. any first hands experience applying this for tech incidents?
  - shahahmed 2y ago
    this is detailed in the Google SRE book: https://sre.google/workbook/incident-response/ https://sre.google/workbook/incident-response/
  - eep_social 2y ago
    I have experience applying ICS-style process to incidents and have delivered training to ~hundreds of engineers at $job. I am partial to this PD doc: https://response.pagerduty.com/training/courses/incident_response/ https://response.pagerduty.com/training/courses/incident_res...
- misswaterfairy 2y ago
  Agreed. ICS is designed to be scalable and flexible (without the marketing fluff that tech companies try to sell). Am firefighter/emergency manager and regularly train and utilise ICS. It works for any incident you throw at it, even a kids birthday party if you really need it to.
jbcranshaw 2y ago
Just curious, what's the backstory? What inspired you to work on this?
pinkmuffinere 2y ago
I love your minimal-but-effective splash page! It looks like it didn’t take too long to build, but it shows what the tool looks like and gives a link to waitlist
nagstler 2y ago
I'm definitely looking forward to this project! Have you considered how Incidental might integrate with other open-source tools? I'd love to use something like this in my OSS project. https://github.com/Multiwoven/multiwoven https://github.com/Multiwoven/multiwoven
- snthpy 2y ago
  I was thinking along similar lines. It would great if incidental and multiwoven used some standard connector library instead of Slack's api so that I can seamlessly use them with other services like Teams which we use at work.
keane 2y ago
Different use case but, in addition to integrating ICS, take a look at Sahana EDEN: https://sahanafoundation.org/eden/features/#core https://sahanafoundation.org/eden/features/#core
efilife 2y ago
Your site doesn't work on mobile
jensenbox 2y ago
What was your thinking for choosing a SPA style app vs something simpler like HTMX? Just curious.
throwaway81523 2y ago
This is the kind of thing where I'd really rather see a clear statement of the problem and a description of the types of solutions that already exist. Then writing a CRUD app is a "mere" exercise.
evnsio 2y ago
As the person who originally wrote the Monzo Response project (https://github.com/monzo/response https://github.com/monzo/response), I expect you'll find some traction in smaller orgs, but when folks start doing things at scale they'll hit an inflection point where running their own incident software/not having folks to log feature requests with will force them to pick something more off-the-shelf. Basically, nobody runs their on-call system on open-source because it's mission critical. At a certain point, IM platforms hit the same level of criticality.
- julianeon 2y ago
  Insightful comment; makes sense.

168 points by sanj001 2y ago

matthewcford 2y ago

We've been building same thing hope to share it soon.

dotancohen 2y ago
Tell us more.

otabdeveloper4 2y ago

> Slack Thanks but no thanks.

shahahmed 2y ago
curious, is this because you expect something other than Slack supported?
- otabdeveloper4 2y ago
  Slack is a piece of shit software. Sorry for being blunt. Yes, I will be that guy.
  - SergeAx 2y ago
    What does your team use instead?
DowagerDave 2y ago
could be worse... Teams cough, cough

allywilson 2y ago

Different auth options (SAML, OAuth, etc.) would be a nice to have. I look forward to the progress on this tool :-)

novia 2y ago

I love to see it. Thank you for building this. This is a problem that's been solved many times over by private companies, and they charge other institutions exorbitant fees for the privilege of using their software. I hope you can get many companies to put skin in the game and contribute towards fixing bugs. It'll be cheaper for them in the long run than paying those external vendors. For those of you complaining about the slack integration in the comments, you know you can just not connect that, right?

dewey 2y ago
> I hope you can get many companies to put skin in the game and contribute towards fixing bugs. It'll be cheaper for them in the long run than paying those external vendors. This would be a nice world to live in, but unfortunately this is very rarely the case as you can see with most open source projects that are used in many companies and are underfunded and understaffed. Most bigger companies value saved time of not integrating something themselves, liability and having someone else to call if something goes wrong higher than saving a few thousand bucks a year for some external vendor. Which makes total sense for something that's not your core business.
lawrjone 2y ago
Don't these people already have the option of running open-source tools like Netflix's Dispatch or Monzo's Response? If they have the open-source options why would they pay for the hosted services?
- rm_-rf_slash 2y ago
  Support, liability protection, SLA…there’s a reason people pay for tools they can get for free.

Rickasaurus 2y ago

My pet feature is good and tight Jira (or ticket manager) integration so it opens tickets for the team to put time on, maybe even syncs time? Really nicely streamline so the time to remediate is tracked as part of the team's work.

vindex10 2y ago

I will just share a somewhat similar project: https://github.com/netflix/dispatch https://github.com/netflix/dispatch Also open source, also Python, also incident management, also custom severities (but not as much of custom roles, afaik) :) Has some integrations with slack, but not focused on Slack particularly. Can be a good project to learn from as well :) My relation to it: I only contributed with a couple of pull requests there :)

brunoqc 2y ago
It looks nice. I wish it would support prometheus/lokio/grafana.
SoftTalker 2y ago
Best Practical, makers of the venerable "RT" request tracker, also make an IR system based on that technology. https://bestpractical.com/rtir https://bestpractical.com/rtir I haven't used their Incident Response but used the basic RT for years. It's solid and never gave us any trouble. It is all (or mostly) written in Perl however if that is a concern. Open-source and free to run on your own, or you can pay for cloud hosting and support.

synack 2y ago

Use the semantics of the standard Incident Command System. Emergency responders have spent decades figuring out the best way to organize for these situations. Tech orgs should leverage that work. https://en.wikipedia.org/wiki/Incident_Command_System https://en.wikipedia.org/wiki/Incident_Command_System https://training.fema.gov/nims/ https://training.fema.gov/nims/

joseferben 2y ago
this looks interesting. any first hands experience applying this for tech incidents?
- shahahmed 2y ago
  this is detailed in the Google SRE book: https://sre.google/workbook/incident-response/ https://sre.google/workbook/incident-response/
- eep_social 2y ago
  I have experience applying ICS-style process to incidents and have delivered training to ~hundreds of engineers at $job. I am partial to this PD doc: https://response.pagerduty.com/training/courses/incident_response/ https://response.pagerduty.com/training/courses/incident_res...
misswaterfairy 2y ago
Agreed. ICS is designed to be scalable and flexible (without the marketing fluff that tech companies try to sell). Am firefighter/emergency manager and regularly train and utilise ICS. It works for any incident you throw at it, even a kids birthday party if you really need it to.

jbcranshaw 2y ago

Just curious, what's the backstory? What inspired you to work on this?

pinkmuffinere 2y ago

I love your minimal-but-effective splash page! It looks like it didn’t take too long to build, but it shows what the tool looks like and gives a link to waitlist

nagstler 2y ago

I'm definitely looking forward to this project! Have you considered how Incidental might integrate with other open-source tools? I'd love to use something like this in my OSS project. https://github.com/Multiwoven/multiwoven https://github.com/Multiwoven/multiwoven

snthpy 2y ago
I was thinking along similar lines. It would great if incidental and multiwoven used some standard connector library instead of Slack's api so that I can seamlessly use them with other services like Teams which we use at work.

keane 2y ago

Different use case but, in addition to integrating ICS, take a look at Sahana EDEN: https://sahanafoundation.org/eden/features/#core https://sahanafoundation.org/eden/features/#core

efilife 2y ago

Your site doesn't work on mobile

jensenbox 2y ago

What was your thinking for choosing a SPA style app vs something simpler like HTMX? Just curious.

throwaway81523 2y ago

This is the kind of thing where I'd really rather see a clear statement of the problem and a description of the types of solutions that already exist. Then writing a CRUD app is a "mere" exercise.

evnsio 2y ago

As the person who originally wrote the Monzo Response project (https://github.com/monzo/response https://github.com/monzo/response), I expect you'll find some traction in smaller orgs, but when folks start doing things at scale they'll hit an inflection point where running their own incident software/not having folks to log feature requests with will force them to pick something more off-the-shelf. Basically, nobody runs their on-call system on open-source because it's mission critical. At a certain point, IM platforms hit the same level of criticality.

julianeon 2y ago
Insightful comment; makes sense.