In OpsGenie, we have added GitHub's StatusPage as an external service:
You'll see in the screenshot above that there appear to be 4 open incidents with the service. However, each of these incidents are closed on GitHub's end. For example, here is a link to the first incident in the list above ("Incident with Actions and Pull Requests - Feb 19, 2023, 8:54 AM") https://www.githubstatus.com/incidents/pd991fsqrw9s.
Additionally, the incident creates an alert that does not close upon resolution of the incident, even though the Statuspage integration has updated the alert with `Incident Status=resolved`:
I have tested other Statuspage external services, and they behave similarly. Is additional configuration required in order to close these incidents and alerts once Statuspage reports the incident as resolved?
@Shivam Naik I am seeing the same thing on my end as well (I've got 5 external status pages linked and they all have this problem of alerts not being updated when the associated incident is resolved). I'm seeing the same behavior with all our external status pages and it's definitely a bit frustrating. I tried setting a notification policy to auto close these alerts but it never winds up getting triggered. Looks like there is a ticket open for this from February of this year (https://jira.atlassian.com/browse/OPSGENIE-38). Would be great if this got prioritized considering that Statuspage and OpsGenie are both Atlassian products and this sync functionality was introduced back in 2019 (https://www.atlassian.com/blog/it-service-management/opsgenie-external-services).
Hey @Eric Hayes regarding the notification policy to auto close those alerts that you posted in the comments of https://jira.atlassian.com/browse/OPSGENIE-38. That policy should work for alerts created after you created/enabled the policy, I have a similar policy that's working. When I was creating my policy I noticed it wasn't working for existing alerts, and after much digging through documentation I figured out the alert workflow needs to be re-triggered for the existing alerts. Bulk select all of the alerts you want closed, acknowledge and then unacknowledge them. That should cause them to be reprocessed and closed by your auto close policy.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Brian Waligorski ,
Happy to help!
I will get some testing done on my site to reproduce that behavior and see what the functionality is there. I would recommend opening a Support Ticket so we can look at this more closely in the context of your site, but it could have to do with where the webhook is established. While the third party component is present on your Statuspage site, it could be that its not sending Opsgenie needed content directly as a result of the third party site not being integrated with Opsgenie itself via the webhook. But this will need some testing, and I will follow up here once I know more!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Shivam Naik were you able to test this and find anything out? I have external services created for many of the Atlassian products, and their service status pages exhibit the same behavior that Brian is experiencing.
Here's a screenshot of the Confluence service status page. The status for all of those "Open" incidents on Statuspage is resolved.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.