Open a Jira ticket with a summary you choose when a monitor goes down. Useful when an outage needs follow-up work rather than just a notification, and when that work belongs in the same tracker as everything else.
Not every outage needs a ticket. The ones that do are usually the ones where the fix is not finished when the service comes back.
A service that goes down repeatedly needs work, not just alerts. A ticket puts that work somewhere it will be prioritised.
When an incident warrants a review, a ticket is where that review gets scheduled and tracked.
If the fix belongs to a team that does not watch your alerting channels, a ticket reaches them through the process they already use.
Where outages need a documented trail, a ticket per incident creates one in the system your organisation already audits.
A ticket for a two-minute blip is noise in your backlog. Delay it so only real outages create work items.
Because flows belong to individual monitors, reserve ticket creation for the services where follow-up is genuinely expected.
Connect a project, write your summary, and let genuine incidents open themselves.