Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

is there a way to correct the components affected by an incident?

We had an incident recently that Statuspage shows affecting three components, when in reality it only affected one. Is there a way to edit an incident and correct which components were affected? It doesn't seem possible, using the edit icons on the various stages of the incident only allow for editing the text associated with them. We've backfilled the incident on a specific component that was affected but which wasn't showing in the histograph, but this did not resolve the original issue. 

1 answer

0 votes
Scot Wilson
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Feb 07, 2021

Hi Cory - Welcome to Statuspage!

It's not possible to edit the components that were included in an Incident, and it would not be ideal to allow this to happen.

Those entries in an incident are part of the historical record, and show which components were included and notifications sent for. If you were able to edit which components were included in an incident you would have the case where your notifications for components affected in an incident differs from what the incident shows and this would imply that your incident reporting is unreliable.

A better way of handling this would be to include in your resolved message, or your Postmortem that these components were not actually affected and remained available during the incident.

What you can do is edit/correct the uptime for that component, by editing the component and editing the historical uptime data - as detailed in 


Hi Scot,

Completely disagree with this. When an incident occurs it's often unclear what the component actually is. An incident manager can guess it's about a specific component or set of components, but it's not until later in the incident where they can realize, no, it was something else. That's why there's the investigating phase, right? We are trying to identify the cause and not the symptoms.

Yes, we can edit the component to adjust the downtime, but then on the UI you'd hover over a red block or red line and have no related incidents. Why was this set of days red? No idea, because there's no information about it. I can't read the post-mortem because there is none. There's no association with an incident.

The idea that you're divorcing the visual UI from the intent of the UI and asking folks to instead just plug a bunch of text into the post-mortem is really short sighted. One core audience for statuspage is our executive team. They need easy-to-follow data that very clearly links why an outage occurred on a given day. Asking them to dig through post-mortems isn't a winning strategy.

I love most of the Atlassian stack, but it's bizarre Atlassian would draw the line on allowing us to edit the component. Even if you guys don't think it's best practice - so what? Give your customers the option to make that determination. I can't give a true and accurate representation of what really happened when I can't even go back and correct a set of components.

Without this feature, I don't see how I can rely on Statuspage to actually produce accurate data. If Atlassian applied this logic to JIRA, why bother having custom fields? After all, if a customer changed the custom field it would potentially make the report unreliable. Come on guys. You're overthinking this. 

Scot Wilson
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Jan 08, 2023

Hi Tim!

You're absolutely able to update an Incident while it is in progress, and include new components, remove components, and update the status of each components at any stage. You're completely correct in thinking that while the incident is in Investigating phase that it should be feasible for you to modify which components are being affected by the incident, and we support that by allowing you to update the incident to change these details.

Our product designers made the decision to not allow you to edit an incident once it is closed, because it would be a confusing experience for users (especially SMS subscribers) that will receive notices, after they have been told than an incident is over. There's also the issue where your users will have received incident notifications at various points in time, and if it was possible to modify an incident post closure, these notifications would not match the what the incident says happened.

We encourage our customers to use the Monitoring status for incidents until they are sure everything has been identified and commented on, before they close them out and turning them to a read-only status.

In thinking about this as a feature request, where a customer should be able to add a component as affected to a closed out incident we would consider that functionality would be available to you by choosing to create a backfilled incident which would include those other components, so they are associated with an incident.

The other feature requests I believe may be warranted here, is that you should be allowed to modify the start time for a component when added to an existing incident. Currently when we add a component to an incident, the outage for that component starts from the point we update the incident, but your discussion indicates that you want to be able to set this date to be prior to this time point (perhaps at incident start). And the alternate side of this would be that if I update an incident to remove a component, there should be the option to remove the outage associated with the incident since the component wasn't being affected by the incident.

Would these features cover the scenarios you are envisioning?

I've hit the exact scenario that @Tim Fostik has explained. Understanding the correct service impact could take a while post resolution. There should be a few roles that can add/update/remove status page service components with the "Do not notify" option. This way corrections can be made in the backend for accurate service reporting and users don't have to be notified. 

PS: I did try to backfill an incident and currently there's no option to choose a service component.

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events