Welcome to your weekly Jira Ops Early Access program update, where we’re sharing news and updates on Jira Ops progress as we work toward our 1.0 release. If you ever want to drop us feedback or ideas, you can leave a comment on this post or shoot us an email:jira-ops-feedback@atlassian.com.

And you can learn more about Jira Ops and start using it for freeright here.

Your incident team can now edit and hide timeline updates in Jira Ops. This is a great way to make sure your timeline is a curated source of truth for the incident.

Not only does this help the team get up to speed and know what’s happened during the incident. But an accurate, descriptive timeline is your secret weapon during the postmortem. Here you’ll be able to easily understand what happened and when. You’ll be better prepared to spot the kind of changes that will cut down on future incidents.

An effective postmortem helps you understand all contributing root causes of the incident, document the incident for future reference and pattern discovery, and plan preventative actions to reduce the likelihood or impact of the incident repeating itself.

From Day 1 we built Jira Ops with the postmortem in mind, because we know it plays such an important role in incident management.

At Atlassian we use Confluence to document our postmortems. Here the team can all comment, weigh in, and align on next steps.

We’re building out postmortems with a Confluence integration as our next new feature. Here’s a look at some initial designs. We’d love to hear what you think.

First up, you can see there’s a new action available on this issue now that the postmortem is resolved: “Create postmortem.”

From there, you’ll open a new postmortem template on a Confluence page. That postmortem document will now always be linked to the incident issue.

You’ll also be able to see postmortems across incidents and track which incidents still need a postmortem.

Finally, this PDF shows our current thinking for the postmortem template that will be populated from Confluence.