Run a Jira Customer Portal Outage Drill

Run a simulated portal outage through triage, recovery, and prevention in Jira.

Introduction

30 Second Summary

When a customer-facing service goes down, every minute brings new questions from customers and responders. A strong service desk record keeps the response clear while the pressure rises.

In this project, you will run a fictional customer portal outage drill in Jira Service Management Cloud. You will turn the complete response into evidence for a service desk interview.

What You'll Build

Picture opening one resolved outage record in an interview that proves how you triaged the incident, communicated through uncertainty, verified recovery, and learned from the result.

By the end of this project, you'll have:

A customer-facing outage request with a unique key. You can open it from an agent queue to demonstrate complete triage.
An activity timeline that clearly separates internal coordination from customer updates. It shows how you maintained communication ownership during an active outage.
A resolved incident record backed by HTTP 200 recovery evidence. A successful synthetic login confirms the customer journey. A 22-minute restoration result supports your blameless post-incident review. A concise STAR interview story turns the evidence into an interview answer.
Secret Mission: Use Five Whys to turn the outage into an owned preventive action for problem management.

Are there any prerequisites?

No prior service desk experience is required. The guide covers every account and site setup step in Microsoft Edge on Windows.

Before We Start

This is your moment to commit to running Northstar's fictional customer-portal outage drill. You will practise a traceable incident response that becomes evidence you can discuss in a service desk interview.

Set Up Your Free Incident Workspace

A realistic incident response drill needs one shared service desk workspace. Disconnected notes cannot show a traceable workflow.

You'll use Microsoft Edge to create a verified Atlassian account.

Your Jira Service Management Cloud site will contain the Northstar Service Desk space. Its customer portal will provide the entry point for the outage drill.

In this step, get ready to:

Activate your Free Jira Service Management Cloud site.
Create the Northstar Service Desk space.
Publish the production-outage request type.

Create your account and Free site

Your Atlassian account identifies you across the site. Email verification confirms that the account belongs to you.

Press the Windows key to open the Windows search bar.
Type Microsoft Edge into the search bar.
Press Enter to open Microsoft Edge.
Navigate to https://www.atlassian.com/try.
Find Jira Service Management on the page.
Select Try cloud.

Keep This Lab Free

The intended path is Free forever for 3 agents. Atlassian asks for payment details when you upgrade from Free to a paid plan.

Create a new Atlassian account when prompted.
Open the verification message from Atlassian in your email inbox.
Follow the verification link in the message.
Return to the Microsoft Edge tab from earlier.

Your verified account can now continue through the site setup flow.

Choose an available site URL when prompted.
Complete the site setup without selecting a paid-plan upgrade.

A new site starts on the Free plan. The site setup should continue without requesting payment.

Leave payment details empty if a billing screen appears.
Skip any invitation that would increase the site beyond three agents.

You've cleared the sign-up stage. Your verified account is now signed in to an active Free site.

Can't Reach Your New Site?

Check your spam folder for the Atlassian verification message.
Reopen the signup page if the verification link has expired.
Sign in again from the same Microsoft Edge tab after verifying your email.

Help me complete my Atlassian account verification and Free site setup.

Build the Northstar service space

A service space keeps incoming work visible through queues. The IT service management template gives the drill a service-focused workflow.

Select the control next to Spaces in the Jira sidebar.
Choose the Service management category.
Select the IT service management template.
Select Use template.

You'll see the form for configuring the new service space.

Why Use This Template?

The IT service management template is designed for teams that manage service work. It gives this outage drill the right incident-management context.

Select company-managed if a management-type choice appears.
Enter Northstar Service Desk as the space name.

The setup form now identifies the company-managed Northstar workspace.

Enter NSD as the space key.
Select Create space.

Jira creates the Northstar Service Desk space with the NSD key.

Select Continue to space if that screen appears.

The Northstar Service Desk space is ready to receive customer requests.

Can't Create the Space?

Check that the space name is Northstar Service Desk.
Check that the space key is NSD.
Return to the template selection if the IT service management template is missing from the form.

Help me create the Northstar Service Desk space.

Add the outage request type

A request type gives customers a specific portal option for reporting an outage. Mapping it to the Fault work type connects that portal option to the agent workflow.

Select Space settings in the Northstar Service Desk space.
Select Request management.
Select Request types.
Select Create request type.
Select Create blank.

You'll see a blank request-type form ready for the customer-facing outage details.

How Does the Mapping Work?

Customers see the request type in the portal. Agents receive the submitted request as a Fault work item inside the service space.

The portal group setting is a little fiddly because it sits among the request-type details. Keeping the outage option inside IT support makes it easy for customers to find.

Enter Report a production outage as the request type name.
Enter Report a service interruption affecting customers as the description.

The form now names the customer scenario and explains when to use it.

Choose IT support as the existing portal group.
Map the request type to the Fault work type.

The form now connects the customer portal option to the Fault workflow.

Select Save.

Before you check, predict where the new outage option will appear in the portal.

Return to the Northstar Service Desk portal in the Microsoft Edge tab from earlier.
Select Raise a request.

You've built the front door for the outage drill. You'll see Report a production outage inside the IT support portal group.

Request Type Missing From the Portal?

Return to Request types to confirm that the request type was saved.
Check that Report a production outage belongs to the IT support portal group.
Check that the request type maps to the Fault work type.

Help me make my outage request type visible in the customer portal.

Workspace Checkpoint

Your verified Atlassian account is signed in through Microsoft Edge.

Your active Jira Service Management Cloud site remains on Free with no payment details or paid-plan upgrade. The agent count remains at three or fewer.

Your company-managed IT service management space is named Northstar Service Desk with the NSD key.

Your custom outage request type is visible in the IT support portal group. It is mapped to the Fault work type.

Your incident workspace now has a customer-facing intake path. Next up, you'll raise the fictional outage and turn it into a triaged service desk record.

Raise and Triage the Outage

Your Northstar intake path is ready, so the next move is to put a realistic outage through it. This step turns a simulated alert into a traceable work item in Jira Service Management Cloud.

Responders need a shared view of impact. They also need a named owner.

Stakeholders need a next-update time. A vague status leaves these needs unanswered.

In this step, get ready to:

Create a customer-facing outage work item.
Triage the outage using an owner plus a justified priority.
Test what a vague internal note fails to communicate.

Submit the outage report

An outage report anchors every later action to one record. This request captures the simulated alert through a summary plus drill evidence.

Select Report a production outage on the Raise a request portal.
Enter Customer portal unavailable after identity configuration rollout in the Summary field.
Enter the scenario details by copying the text below into the Description field:

Source: Synthetic availability alert at T+00
Symptom: All regions return HTTP 503; customers cannot sign in or submit requests.
Change correlation: Identity configuration version 42 was deployed at T-10.
Training SLA: Acknowledge within 15 minutes and restore within 60 minutes.
Security and data-loss status: Unknown at detection; investigation required.

What do these details establish?

The Source fixes the detection point at T+00.
The Symptom records the customer journey that has failed.
The Change correlation gives responders a recent change to investigate.
The Training SLA records fictional response targets for this drill.
The Security and data-loss status preserves uncertainty at detection.

Submit the completed request using the control at the bottom of the form.

You have crossed the intake boundary: the fictional alert is now a traceable work item. You'll see a unique Jira-assigned key beginning with NSD.

Record the Jira-assigned work item key here: your NSD key.

Request did not appear?

Confirm that the Summary field contains the outage title.
Confirm that every required field on the request form has a value.
Submit the request again using the control at the bottom of the form.

Ask for help if the portal still does not create the request: Help me troubleshoot why my Jira Service Management Cloud request is not appearing after submission.

Triage the work item

Incident triage turns an incoming request into an actionable record. A queue gives agents one place to find incoming work.

Impact measures the effect on business processes. Urgency measures how quickly significant business harm could occur.

Priority captures the request's relative importance. An active outage affecting every customer justifies High priority.

Select Queues in the Northstar Service Desk sidebar.
Locate the work item using your NSD key.
Select the outage work item.
Select the Assignee field.
Choose Assign to me.
Select the Priority field.
Choose High.

That is the first triage decision locked in: ownership is now explicit. The High priority reflects the active customer impact.

Select the Labels field.
Add incident as a label.
Add customer-portal as a second label.
Select the Description field.
Add Impact is high because all customers are blocked and urgency is high because the failure is active now. to the description.

You should now see yourself as the assignee. The work item also shows High priority.

The Labels field shows incident plus customer-portal.

Missing a triage field?

Scroll through the work item's details to find fields that sit below the visible area.
Select the work item again if the queue is still showing only the request list.
Confirm that incident appears as its own label.
Confirm that customer-portal appears as its own label.

Ask for help if a required field remains unavailable: Help me find the Assignee, Priority, Labels, or Description field in my Jira Service Management Cloud work item.

Test a vague internal note

An internal note keeps responder coordination hidden from customers. The Activity section lets you test whether a short update carries enough operational context.

Before you save the note, do you think Looking into it. tells another responder enough to take over?

Select Activity in the work item.
Select Add internal note.
Enter only Looking into it..
Select Save.

You'll see Looking into it. under Activity. It does not identify the impact.

This gap is intentional

The note gives responders no ownership. It also gives stakeholders no next-update time.

It records no response action. It names no escalation path.

Before the final check, do you expect the triage fields to remain attached after the internal note was added?

Return to Queues from the Northstar Service Desk sidebar.
Select your NSD key.
Inspect the work item's triage fields.
Review the note under Activity.

What should I see?

The work item shows your NSD key. Its Assignee is you.

Its Priority is High. Its labels are incident plus customer-portal.

The Description retains the five drill details. It also records the impact and urgency reasoning.

The Activity section contains the internal-only note Looking into it..

Missing the internal note?

Return to Activity in the outage work item.
Confirm that Looking into it. was entered through Add internal note.
Save the internal note again if it is absent.

Ask for help if the note still does not appear: Help me find or save an internal note in the Activity section of my Jira Service Management Cloud work item.

That is the triage foundation complete: your outage has evidence, ownership, and a visible communication gap. Next up, you'll replace the vague note with a structured incident update.

Communicate the Incident

Your Jira Service Management Cloud work item now records the incident's business severity. Its only internal update is still Looking into it. That note creates the information gap this step fixes.

Internal notes coordinate responders behind the scenes. Customer replies give affected people a clear status. A visible workflow status shows that investigation is underway.

In this step, get ready to:

Create a structured internal update with ownership, current status, next steps, and escalation.
Publish a separate customer acknowledgement with the T+15 commitment.
Verify the separated communication timeline under an active-investigation status.

Write the structured internal update

An internal note gives responders one source of truth without exposing technical coordination to customers. This update replaces vague progress with clear ownership plus a recovery plan.

Return to Activity in the open outage work item.
Select Add internal note.
Copy this structured update into the note editor:

All customer portal sign-ins are failing with HTTP 503 after identity configuration version 42 was deployed.

Current Status:
Incident owner: Service Desk
Impact: all portal customers blocked
Security or data loss: no evidence yet
Working hypothesis: identity configuration incompatibility

Next Steps:
Escalate to the Identity Platform team
compare versions 41 and 42
prepare rollback to version 41
send the next update at T+15

Escalation:
Identity Platform team engaged as second-line support
Service Desk retains communication ownership

How the Update Closes the Gap

The opening summary anchors the update to the customer impact plus the correlated change.
The current status names the owner plus the working hypothesis.
The next steps give responders a recovery sequence plus a communication deadline.
The escalation section gives second-line support a clear role while Service Desk retains communication ownership.

Select Save.

You should see the structured update under Activity as an internal note. The owner, escalation path, recovery actions, and T+15 deadline are now visible to responders.

Can't See the Internal Update?

Confirm that you selected Save after entering the note. Make sure you used Add internal note for this responder-only update.

Ask for help checking the internal update flow:

Send the customer acknowledgement

A customer acknowledgement confirms that the outage is being handled. It also commits the Service Desk to a specific update time without presenting an unconfirmed cause as fact.

In Activity, select Reply to customer.
Copy this acknowledgement into the reply editor:

We are investigating a customer portal sign-in outage. Customers may receive HTTP 503 errors. The Service Desk and Identity Platform teams are working on recovery, and the next update will be provided at T+15.

Why This Reply Works

The reply describes the customer-facing symptom in plain language. It names the responding teams without exposing the unconfirmed technical hypothesis.

The T+15 commitment tells customers when they can expect more information. A clear deadline reduces uncertainty while the investigation continues.

Select Save.

You should see the acknowledgement as a customer-visible reply under Activity. It remains visually separate from the internal technical update.

Customer Reply Missing?

Confirm that you selected Reply to customer before entering the acknowledgement. Check that you selected Save after pasting the message.

Ask for help finding the customer-visible reply:

Move the outage into active investigation

The workflow status communicates the incident's current stage at a glance. Your site's available status names may vary because the workflow controls which transitions appear.

Select the current status control on the outage work item.
Choose the available transition or status that represents active investigation.

The status control should now indicate that investigation is underway.

Before you refresh, what evidence do you expect to prove that internal coordination remains separate from customer communication?

Refresh the work item in Microsoft Edge.
Inspect Activity.

You should see the original Looking into it. note plus the structured internal update. Both entries remain internal to responders.

You should also see the separate customer acknowledgement with its T+15 commitment. The status control should continue to show active investigation.

Timeline Incomplete?

Review Activity to identify which communication entry is missing.
Use Add internal note for the responder update.
Use Reply to customer for the customer acknowledgement.

Ask for help checking the completed communication timeline:

That information gap is closed. Your work item now proves who owns communication, who supports recovery, and when customers receive the next update.

Your outage now has a traceable communication record. Next, you will document the rollback and verify that the full customer journey has recovered.

Restore and Verify Service

Your earlier Jira Service Management Cloud updates established clear ownership. They also gave customers a firm next-update time.

A configuration change alone cannot close an incident. You need evidence that the service works before you declare restoration.

In this step, get ready to:

Document the configuration incompatibility as the working cause.
Record recovery evidence for the customer portal journey.
Resolve the outage with a customer-visible confirmation.

Document the diagnosis and rollback

A diagnosis note connects the symptoms to the recovery action. Its timestamps create a traceable route from comparison through rollback to stable monitoring.

Select Add internal note in the work item's Activity section.
Enter T+10: version 42 differs from version 41 in the identity provider schema as the first line.
Enter T+15: second-line support rolls back to version 41 on the next line.
Enter T+18: availability check returns HTTP 200 in all regions on the next line.
Enter T+19: synthetic login and request submission succeed on the next line.
Enter T+22: monitoring remains healthy and restoration is declared. on the next line.
Add The evidence supports configuration incompatibility as the working cause. as the final sentence.
Select Save.

You have captured the key diagnostic trail. The record now connects the suspected configuration incompatibility to the rollback that restored service.

Why Verify After a Rollback?

A rollback changes the configuration. Restoration evidence shows that the current business impact has ended.

The timeline keeps those moments separate. That makes the final status defensible.

Record the restoration checks

The timeline shows when recovery happened. A verification checklist proves that the portal is reachable.

The checklist also confirms that customers can complete the affected journey. These checks provide the evidence needed for closure.

Select Add internal note in Activity.
Enter this verification note: HTTP 200 in all regions. Synthetic login succeeds. Request submission succeeds. There is no evidence of data loss. There is no evidence of a security event. Rollback owner confirmed. Restoration time: 22 minutes. The fictional 60-minute restoration target was met..
Select Save.

You should now see a second internal note below the diagnosis timeline. It records the technical checks plus the customer-journey checks.

How Is Restoration Time Calculated?

Detection starts at T+00. Restoration is declared at T+22.

The elapsed time is 22 minutes. That sits inside the fictional 60-minute restoration target.

Confirm recovery with the customer

Internal evidence supports the resolution decision. The customer also needs a clear confirmation that the affected journey works again.

Select Reply to customer in Activity.
Enter Service has been restored. Customer portal sign-in and request submission are working normally after the identity configuration rollback. Monitoring checks are healthy, and we will review the incident to prevent recurrence..
Select Save.
Select the work item's current status.
Choose the available transition or status that marks the request Resolved.

Before you refresh, do you expect the resolved record to preserve the full recovery trail?

Refresh the current work item.

You should see Resolved in the status control.

Inspect Activity for the complete incident timeline.

The earlier internal notes remain visible. The customer acknowledgement with its T+15 commitment remains visible too.

The diagnosis note shows the rollback from version 42 to version 41. It ends with restoration at T+22.

The verification note shows HTTP 200 in all regions. It also records the customer-journey checks plus the 22-minute result against the fictional 60-minute target.

The customer-visible reply confirms service restoration. You now have a resolved record that proves recovery with evidence.

Can't Reach Resolved?

Select the work-item status again.
Choose an available transition that ends at Resolved.
Refresh the work item after the transition completes.

If no suitable transition appears, ask for help finding the resolution transition.

Your outage record now proves diagnosis, restoration, verification, and customer closure. Next, you'll turn that evidence into a post-incident review and an interview story.

Create Interview Evidence

Your resolved outage in Jira Service Management Cloud already proves that you can triage an incident through restoration. The timeline gives you concrete evidence for a service desk interview.

The role also expects learning after restoration. This step turns the record into a blameless review. It also captures recovery planning. Finally, it gives you an interview story grounded in evidence.

In this step, get ready to:

Create a blameless post-incident review with the complete outage timeline.
Document recovery objectives plus records-retention actions.
Build a STAR interview story from the resolved incident.

Write a blameless post-incident review

A post-incident review explains what happened after service is stable. A blameless review focuses on systems plus processes. It avoids blaming individuals.

Return to the resolved outage work item from earlier in Northstar Service Desk.
Select Activity.
Select Add internal note.
Paste the review below so its first line identifies the note:

Post-incident review

Leadup
Identity configuration version 42 was deployed at T-10.

Fault
Version 42 differed from version 41 in the identity provider schema. The evidence supports configuration incompatibility as the working cause.

Detection
At T+00, a synthetic availability alert reported HTTP 503 in all regions. Customers could not sign in or submit requests.

Root causes
The working cause was identity configuration incompatibility. The release process did not catch the schema difference before production.

Mitigation and resolution
T+00: The synthetic availability alert detected the outage.
T+10: The identity provider schema difference was identified.
T+15: Second-line support rolled back to version 41.
T+18: Availability checks returned HTTP 200 in all regions.
T+19: Synthetic login and request submission succeeded.
T+22: Monitoring remained healthy. Restoration was declared.
The restoration time was 22 minutes. This met the fictional 60-minute restoration target.

Lessons learnt
What went well: The Service Desk retained communication ownership. Second-line support completed the rollback. Validation covered availability plus the customer journey.
What could improve: The release process needs a schema compatibility check before production. The recovery runbook needs clear rollback criteria.
This review focuses on systems and processes. It does not blame individuals.

How Does This Review Help?

The six headings organize the evidence into a repeatable review format.
The timeline preserves the sequence from detection at T+00 to restoration at T+22.
The lessons turn the outage into process improvements.

Select Save.
Review the new entry in Activity.

You should see Post-incident review followed by all six headings. Strong work. Your resolved record now explains how the response unfolded without assigning personal blame.

Missing a Review Heading?

Compare the saved note with the review above.
Use the note's editing option to restore any missing heading or timeline entry.

Ask for help checking the review structure:

Record continuity and retention actions

A recovery time objective defines the target time for restoring a service. A recovery point objective defines the maximum acceptable data loss measured in time.

A recovery runbook records the checks plus ownership needed during restoration. Records retention defines how long evidence is kept before review and disposal.

Select Add internal note in the Activity section.
Paste the continuity record below so its first line identifies the note:

Continuity and records actions

Recovery objectives
RTO: 60 minutes.
RPO: 0 minutes for this configuration-only rollback.
These objectives apply only to the fictional Northstar drill.

Recovery runbook
Activation criteria: Activate the outage response when customer portal sign-ins fail across all regions.
Rollback to the last known good configuration: Restore identity configuration version 41.
HTTP and synthetic-login validation: Confirm HTTP 200 in all regions. Confirm synthetic login succeeds. Confirm request submission succeeds.
Communications ownership: Service Desk owns internal coordination plus customer updates.
Recovery ownership: Identity Platform owns the configuration rollback. Service Desk verifies the customer journey.

Fictional training records-retention policy
Retain the incident timeline and diagnostic evidence for 12 months; Service Desk Manager owns the record; Security and Legal must approve any real organizational retention rule; review and dispose at the end of the approved period.

What Does This Record Prove?

The recovery objectives define the fictional restoration target plus acceptable data-loss window.
The runbook sections make activation clearer during a future outage.
The retention policy assigns ownership. It also requires approval before a real organization adopts the rule.

Select Save.
Review the new entry in Activity.

You should see Continuity and records actions with the fictional recovery objectives. You should also see the runbook sections plus the training retention policy. That gives your incident record a clear continuity layer.

Missing a Continuity Action?

Check that the saved note records an RTO of 60 minutes.
Check that the saved note records an RPO of 0 minutes for the configuration-only rollback.
Use the note's editing option to restore any missing runbook section.

Ask for help reviewing the continuity note:

Build your STAR interview story

The STAR interview method turns your activity timeline into a concise example you can explain under pressure.

Select Add internal note in the Activity section.
Paste the interview story below so its first line identifies the note:

Interview STAR

Situation
Northstar's customer portal returned HTTP 503 in all regions after identity configuration version 42 was deployed. Customers could not sign in or submit requests.

Task
I owned the initial triage plus incident communication. I needed to establish impact, assign priority, coordinate escalation, and keep customers informed.

Action
I set the priority to High. I assigned ownership. I labeled the work item for incident tracking. I escalated to the Identity Platform team while the Service Desk retained communication ownership. I documented the rollback to version 41. I verified HTTP 200 in all regions. I confirmed synthetic login and request submission. I sent separate internal updates plus customer replies.

Result
Service restoration was declared in 22 minutes against the fictional 60-minute target. Validation found no evidence of data loss or a security event. I documented preventive follow-up for schema compatibility testing.

Incident management restores service. Problem management prevents recurrence.

Why Does STAR Work Here?

Situation establishes the customer impact plus change correlation.
Task states your ownership during the drill.
Action connects your decisions to visible evidence in the work item.
Result closes with the restoration metric plus preventive follow-up.

Select Save.
Review the new entry in Activity.

You should see Interview STAR with four concise sections. The final sentence separates restoration work from recurrence prevention. You now have an interview answer backed by a visible incident record.

Does the Story Feel Too Vague?

Check that the Action paragraph names priority, escalation, rollback, validation, and updates.
Check that the Result paragraph includes 22 minutes against the fictional 60-minute target.
Use the note's editing option to restore any missing evidence.

Ask for help tightening the story:

Verify the completed incident record

Before you check, which three note titles do you expect to find in the resolved record?

Refresh the outage work item.
Confirm that the status control still shows Resolved.
Select Activity.
Find the Post-incident review entry.
Find the Continuity and records actions entry.
Find the Interview STAR entry.

All three entries should be visible in the resolved record. Your completed portfolio incident now connects triage, restoration, resilience, records handling, and interview storytelling.

Secret mission

Find the Recurring Cause with Five Whys

Your incident record explains how the customer portal recovered. Now you will trace the outage back to the missing process control that allowed it. You will finish with an owned preventive action that could stop this class of outage from recurring.

Clean Up Your Resources

Choose whether to keep your outage drill available, leave it untouched for later, or delete the training space entirely. This project uses the Jira Service Management Cloud Free plan, so the intended path has no ongoing cost while you stay within the plan boundary.

Cost warning

The intended path costs $0 while your site stays on the Free plan with three agents or fewer. Selecting a paid-plan upgrade can introduce charges.

Keep the agent count at three or fewer.
Avoid selecting a paid-plan upgrade.
Review the plan shown in Atlassian Administration before adding users.

Resources you used:

Company-managed service space named Northstar Service Desk with the key NSD.
Custom request type named Report a production outage inside the Northstar Service Desk space.
Resolved outage work item with the summary Customer portal unavailable after identity configuration rollout and its retained activity history.

Keep everything running

No action is needed. Choose this option if you want to reuse the service space for future outage drills.

Retain the Northstar Service Desk space with its resolved outage work item.
Use the activity timeline to rehearse your incident response explanation.
Reuse the Report a production outage request type for another fictional scenario.
Keep the site on the Free plan with three agents or fewer.

Pause - I'll come back to this later

Stop using the site while keeping the completed drill available. This browser-only project has no running process that needs to be shut down.

Leave the Northstar Service Desk space unchanged.
Keep the Free plan unchanged.
Avoid adding agents while the site is paused.
Avoid enabling paid features while the site is paused.

Delete - I don't want to use this again

Remove the training space when you no longer need the request type or completed outage record. The 60-day trash period gives you a safety net before permanent deletion.

Select Settings in Jira.
Select Spaces.
Select Manage spaces.
Find Northstar Service Desk in the spaces list.
Select More actions for the space.
Select Move to trash.
Select Move to confirm.

You will see the Northstar Service Desk space in trash. You can restore it during the 60-day trash period.

Permanent deletion cannot be undone. The request type and resolved outage record disappear with the space.

Return to Settings.
Select Spaces.
Select Trash.
Find Northstar Service Desk in the trash list.
Select More actions for the space.
Select Delete permanently.

Your Atlassian account and Free site remain available because this cleanup deletes the Northstar Service Desk training space only.

Nice Work!

You did it! Your resolved Jira Service Management Cloud outage record now tells the complete Northstar incident story from alert to preventive action.

You've learned how to:

Build a customer-facing outage workflow in Jira Service Management Cloud. Use the queue to make incoming work visible. Set ownership to make responsibility clear. Apply High priority because all customers are blocked. Use labels to keep the outage searchable.
Replace a vague incident update with a structured internal note. Publish a separate customer acknowledgement with a clear next-update time. Escalate while retaining communication ownership. Verify recovery before resolving the outage.
Convert a 22-minute restoration timeline into a blameless post-incident review. Define an RTO of 60 minutes. Define an RPO of 0 minutes for the configuration-only rollback. Document a fictional retention policy with clear ownership. Turn the evidence into a STAR interview story.
Secret Mission: Use Five Whys to trace the outage to missing ownership for identity-configuration safeguards. Assign automated schema validation to the Identity Platform Lead. Add a canary synthetic-login test to the same preventive action. Set its due date within 14 days of the drill.

Ready to quiz yourself?