Set Separate Timer for Incident File Removal

[willowweevil]

According to the current logic, the lifetime of incident files is defined by the "resolved" and "unknown" timeouts. However, in some cases, it is necessary to maintain an "Incidents History," and the IMPulse UI is a great place to access this!

But, as mentioned above, incidents are removed after the timeout expires.

Would it be more convenient to allow users to set a separate "removal" timeout for deleting incidents?
Here’s how I envision it working:

1. If an incident is in the "closed" status and the "removal" timeout has not yet expired, Impulse should create a new thread in the messenger, but continue to display the incident in the existing incident bar in the UI.
2. Once the "removal" timeout has passed, the incident should be removed from the UI (as well as deleted as a *.yaml file), and any future alerts would result in a new incident being created.

incident:
  timeouts:
    firing: 30h
    unknown: 6h
    resolved: 12h
    remove: 14d

Let me know if this proposal would break the core philosophy of IMPulse incident management (one incident – one messenger thread – one line in the UI).

[DiTsi]

Hi @willowweevil. I think this is a good suggestion. Most likely, we’ll go with this approach.
Within two weeks, I’ll write here to confirm and share the issue number if it appears.

[DiTsi]

Hi @willowweevil,
We’ve added this to our roadmap — please refer to issue #272.
It’s scheduled for v3.2.0 or v3.3.0.

Thank you for your contribution!