How we report incidents
An incident report is only useful if it is honest and if it arrives while people still care. Ours are published here, kept permanently, and linked from the troubleshooting pages of the product that was affected.
We write one for anything that affected customers, including incidents caused by the platform we run on rather than by our own code.
#What every report contains
Section | What it tells you |
|---|---|
Severity, duration and scope | The headline facts, in a table at the top |
What happened | In plain language, including whether the cause was ours |
Timeline | In UTC, from detection to resolution |
How you would have known | The symptoms, so you can match a report to what you saw |
Customer data | Explicitly stated every time, even when the answer is that nothing was affected |
Resolution | What fixed it, and what if anything was needed from customers |
#What we commit to
We publish incidents caused by our platform provider as well as our own. An outage is an outage from where you are sitting.
We state the data impact explicitly, including when there was none. A report that goes quiet on data is not a report.
We do not quietly edit history. Reports are corrected if they are wrong, and the correction is visible in page history.
Live status is not here. This section is the written record after the fact. For something happening right now, contact support.
#A few things worth knowing
A platform-wide Atlassian incident affects every Forge app, not only ours. We still write it up.
Reports are dated by when the incident happened, not by when the page was written.
If you were affected by something not listed here, tell us. It should be.
#Related
Honest, dated, and kept.
