Creating an incident via API doesn't affect component downtime?

[Philip Colmer]

The API to create an incident has a section where you can define the components affected by the incident, and their individual states.

When I create an incident using this API, any component mentioned in the API data is correctly updated in StatusPage to reflect the new state.

However, when I mark the incident as resolved and mark the components as operational, the uptime for the components is *not* affected.

Is this a bug or by design? If the latter, I'm struggling to understand why. It seems like I've got to mark each individual component as (say) "major_outage" and (ultimately) "operational", even though I've done all that via the incident!

[Mark Campbell-Vincent]

Hi @Philip Colmer -

Thanks for reaching out! If you could provide a screenshot of an example of what you're seeing, I can try to further investigate. Providing your API request will help as well. Also, if you'd like Statuspage support to take a look at your account, you can always open up a ticket here: https://support.atlassian.com/statuspage/

As a follow up question, when you hover over that specific incident time on your component, does it say "Major Outage"?

Looking forward to your response.

[Philip Colmer]

HI @Mark Campbell-Vincent 

Hmmm ... I'm not sure if anything has changed behind the scenes but it seems to be working now.

Thanks :)

Philip

[Philip Colmer]

@Mark Campbell-Vincent 

The only thing that still seems a bit "off" about how the incident is being reported is the "inside" view:

Note how it says "No components were marked as affected by this incident"?

I *think* that this is being caused by how the incident is being created. I'm using xMatters to update StatusPage and the built-in step to create a StatusPage incident doesn't support specifying the component(s) at the time of *creating* the incident, so I've written a custom step that is run straight afterwards that updates the incident with the affected components.

I'll try replacing the built-in step with a modified one that does allow the components to be specified at the creation time.

[Philip Colmer]

@Mark Campbell-Vincent

I was correct - the root cause was the fact that I was updating the affected components after the incident was initially created. Changing the steps in the xMatters workflow so that it is now a single call to create the incident with the affected components results in StatusPage displaying a more logical view:

[Mark Campbell-Vincent]

@Philip Colmer -

Glad you were able to find the root cause! Let me know if I can help with anything else.