Troubleshoot a Web Service in CloudShell

Diagnose and restore a local web service in AWS CloudShell.

Introduction

30 Second Summary

When a customer reports that a page is down, every minute without a clear answer chips away at trust. A calm investigation turns a vague complaint into a fix you can explain.

In this project, you will handle a simulated support incident in AWS CloudShell from a failed request to a restored status page. You will publish the diagnosis plus your customer update in a public GitHub case study.

What You'll Build

You will run a restored status page from the terminal while your incident report walks a reviewer from the failed request to the verified fix.

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

  • A working status page that returns Cloud Support Status plus Operational when you request it through HTTP.
  • An evidence-based diagnosis that compares failed requests with successful requests. Linux process evidence proves the service was listening on the wrong port.
  • A public incident case study that presents the root cause, verified fix, customer update, and reusable troubleshooting runbook.
  • Secret Mission: Diagnose and repair a missing health-check endpoint after observing an HTTP 404 response.

Are there any prerequisites?

You need a Windows computer plus an AWS account. The guide covers free GitHub account setup before verifying every CloudShell command used in the investigation.

Before We Start

This opening checkpoint locks in what you are building before any hands-on work begins. You are treating the project as an AWS CloudShell incident case study that demonstrates cloud-support troubleshooting and customer communication.

Prepare Your Support Workspace

An incident is easier to investigate when access works before the customer report arrives. A missing tool can otherwise become a second problem.

In this step, you will prepare AWS CloudShell as your investigation workspace. You will also verify the GitHub account that later holds your case study.

In this step, get ready to:
  • Open Microsoft Edge on Windows. Launch AWS CloudShell with the default Bash shell.
  • Verify Bash, Python 3, curl, ps, and edit. Record the displayed versions.
  • Create a free personal GitHub account. Verify its email address. Confirm that your profile opens.
Launch AWS CloudShell

AWS CloudShell is a browser-based shell inside the AWS Management Console. Its prompt tells you when the investigation environment is ready.

Why AWS CloudShell?

AWS CloudShell gives you a pre-authenticated shell inside the browser. It provides the troubleshooting environment without creating a separate compute resource.

  • Press the Windows key to open Windows search.
  • Type Microsoft Edge into Windows search. Press Enter.
  • In Microsoft Edge, go to the AWS Management Console sign-in page.
  • Sign in with your AWS account.
  • Select the Search box in the AWS Management Console.
  • Enter CloudShell in the Search box.
  • Select CloudShell from the search results.
  • Wait for the prompt to indicate readiness.

You should see a ready command prompt in the default Bash shell. This proves that your cloud investigation workspace is available.

CloudShell access denied?

CloudShell access depends on the permissions assigned to your AWS identity. Ask your AWS administrator to grant the managed policy AWSCloudShellFullAccess.

Help me troubleshoot access to AWS CloudShell. If access still fails, share the policy name with your AWS administrator or the NextWork community.

Verify the troubleshooting tools

CloudShell software is updated regularly. Recording the versions shown in your own session gives your investigation accurate environment evidence.

Before you run these checks, which five tools do you expect CloudShell to identify with version information?

  • Print version information for every required tool by running these commands:
bash --version
python3 --version
curl -V
ps --version
edit --version

What Do These Checks Prove?

  • The bash result identifies the shell available for your investigation.
  • The python3 result confirms that Python 3 is ready.
  • The curl result confirms that you can make local HTTP requests later.
  • The ps result confirms that you can inspect running processes.
  • The edit result confirms that the CloudShell visual editor is available.
  • Review the output from each version check.
  • Record each displayed version in the checkpoint below.

Each command should print version information. Together, the five results prove that the tools required for the incident are available.

Missing Version Output?

  • Check that the failed command matches the command shown above.
  • Run the failed command again after the CloudShell prompt returns.
  • Help me troubleshoot a missing CloudShell tool. Share a redacted copy of the output in the NextWork community if you still need help.
Create and verify your GitHub account

Your case study needs a reviewable home later. Setting up GitHub now keeps account verification outside the incident workflow.

Keep AWS Details Separate

GitHub asks for its own sign-in details during account creation. Your AWS password, credentials, and account identifiers stay out of every GitHub field.

  • In Microsoft Edge, go to https://github.com/signup.
  • Complete the sign-up form using a personal email address.
  • Open the verification message that GitHub sends to your personal email address.
  • Complete the email verification from that message.
  • Return to GitHub in Microsoft Edge.

GitHub should confirm that your email verification is complete. Your personal account is now ready to create repositories.

Email Verification Stuck?

  • Check your inbox for the GitHub verification message.
  • Check your spam folder if the message is missing.
  • Help me finish GitHub email verification. Ask the NextWork community for help if the verification message still does not arrive.

Before the final check, do you expect both the technical workspace and the publishing account to be ready?

  • Switch back to the AWS CloudShell terminal from earlier.
  • Confirm that your investigation notes include a displayed version for Bash, Python 3, curl, ps, and edit.
  • Return to GitHub in Microsoft Edge.
  • Open your profile from the account menu.

Your GitHub profile should open under the verified personal account. That completes the second readiness signal for your support workspace.

Your access, tool evidence, and publishing account are ready. Next, you will launch a working status page that gives the incident a reliable baseline.

Launch the Status Page

Your investigation tools are ready in AWS CloudShell. A useful support incident needs a known-good baseline before a failure tells you anything.

The HTML page in this step proves that the content loads through a local HTTP request. The customer-reported endpoint remains untested.

In this step, get ready to:
  • Create a directory for the incident files in CloudShell.
  • Build the Cloud Support Status page with its final content and styling.
  • Serve the page locally and confirm that its HTML reaches the terminal.
Create the project file

A dedicated directory keeps the page separate from your other CloudShell files. It also gives the local server one clear directory to serve.

  • Switch back to the AWS CloudShell terminal in Microsoft Edge.
  • Create the mysub_dir directory and move into it by running these commands:
mkdir mysub_dir
cd mysub_dir

What do these commands do?

  • The first command creates the mysub_dir directory in your CloudShell home directory.
  • The second command makes mysub_dir your current directory.
  • Create index.html in mysub_dir by running this command:
edit index.html

What does this command do?

The edit command opens index.html in the CloudShell visual editor. Saving the empty editor creates the file inside mysub_dir.

  • Select the empty editor pane.
  • Add the page structure by pasting this code:
<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Cloud Support Status</title>
</head>
<body>
  <main>
    <h1>Cloud Support Status</h1>
    <p class="status">Operational</p>
    <p>The support status page is responding successfully.</p>
  </main>
</body>
</html>

What does this code do?

  • The document metadata gives the page a browser title and supports different screen sizes.
  • The main element groups the information that customers need to see.
  • The status class identifies the operational label for styling later.
  • Press Ctrl+S to save index.html.
  • Close the index.html editor tab.
  • Return to the CloudShell terminal.
  • Confirm that the file exists by running this command:
ls

What should I see?

The terminal output includes index.html. This confirms that the page was saved in mysub_dir.

Cannot see index.html?

Return to the editor tab if it is still open. Press Ctrl+S before closing it.

Check that the terminal prompt still shows mysub_dir before you run ls.

Help me find why index.html was not saved in mysub_dir.

Serve the baseline

The page now gives the built-in Python HTTP server something to return. Running the server in the background keeps the same terminal available for your test request.

  • Start the local server from mysub_dir by running this command:
python3 -m http.server -d ./ &

What does this command do?

  • The Python module starts a simple local web server.
  • The -d ./ option serves files from your current mysub_dir directory.
  • The trailing & runs the server in the background so the terminal prompt returns.

You return to a fresh prompt while the server continues running. The page is available through localhost inside the same CloudShell environment.

Before you run the request, make a quick prediction about whether the terminal returns your page content or a connection failure.

  • Request the page from the server's default port by running this command:
curl http://localhost:8000/

What should I see?

The terminal prints the HTML from index.html. The response contains Cloud Support Status and Operational.

Page content missing?

Check that the server command included the trailing &. Confirm that you launched it from mysub_dir.

Check that the request uses port 8000 and ends with a forward slash.

Help me troubleshoot my local CloudShell status page.

Your first baseline works. CloudShell can serve the status page content through a local request.

Style and verify the page

The content already proves that the server can find the page. CSS now turns that plain response into the finished status-page design while the server keeps running.

  • Reopen index.html by running this command:
edit index.html

Why reopen the file?

The running server reads the saved version of index.html for each request. Editing the same file updates what the next local request returns.

  • Find the line containing <title>Cloud Support Status</title>.
  • Place your cursor on the next line.
  • Add the page layout styles by pasting this code:
  <style>
    body {
      margin: 0;
      min-height: 100vh;
      display: grid;
      place-items: center;
      background: #0f172a;
      color: #e2e8f0;
      font-family: Arial, sans-serif;
    }

    main {
      width: min(90%, 560px);
      padding: 2rem;
      border: 1px solid #334155;
      border-radius: 12px;
      background: #1e293b;
      box-shadow: 0 18px 45px rgba(0, 0, 0, 0.3);
    }
  </style>

What do these styles do?

  • The body styles center the page content against a dark background.
  • The main styles create the bordered card that holds the service status.
  • The width rule keeps the card readable on narrow and wide screens.
  • Press Ctrl+S to save index.html.
  • Close the index.html editor tab.
  • Return to the CloudShell terminal.
  • Confirm that the saved response includes the new background style by running this command:
curl http://localhost:8000/

What changed?

The response now includes background: #0f172a inside the page source. This proves that the running server reads your latest saved file.

Cannot see the new styles?

Reopen index.html and confirm that the style element sits between the title and the closing head tag.

Press Ctrl+S again before repeating the request.

Help me check why curl returns an older version of index.html.

  • Reopen index.html by running this command:
edit index.html

What are you adding next?

The final rules separate the heading from the top of the card. They also turn the operational status into a rounded green label.

  • Find the </style> line.
  • Place your cursor at the start of that line.
  • Add the heading and status styles by pasting this code:

    h1 {
      margin-top: 0;
    }

    .status {
      display: inline-block;
      padding: 0.5rem 0.8rem;
      border-radius: 999px;
      background: #14532d;
      color: #dcfce7;
      font-weight: 700;
    }

What do these styles do?

  • The h1 rule removes extra space above the page heading.
  • The .status rule gives the operational label its shape and colours.
  • The bold text makes the service state easy to scan.
  • Press Ctrl+S to save index.html.
  • Close the index.html editor tab.
  • Return to the CloudShell terminal.

✔️ Awesome, I've got everything!

Your saved file now contains the complete Cloud Support Status page.

ⓧ I'd like to double check the full code

  • Compare index.html with this complete reference:
<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Cloud Support Status</title>
  <style>
    body {
      margin: 0;
      min-height: 100vh;
      display: grid;
      place-items: center;
      background: #0f172a;
      color: #e2e8f0;
      font-family: Arial, sans-serif;
    }

    main {
      width: min(90%, 560px);
      padding: 2rem;
      border: 1px solid #334155;
      border-radius: 12px;
      background: #1e293b;
      box-shadow: 0 18px 45px rgba(0, 0, 0, 0.3);
    }

    h1 {
      margin-top: 0;
    }

    .status {
      display: inline-block;
      padding: 0.5rem 0.8rem;
      border-radius: 999px;
      background: #14532d;
      color: #dcfce7;
      font-weight: 700;
    }
  </style>
</head>
<body>
  <main>
    <h1>Cloud Support Status</h1>
    <p class="status">Operational</p>
    <p>The support status page is responding successfully.</p>
  </main>
</body>
</html>

Before the final request, predict whether the response contains both the page heading and its operational status.

  • Verify the completed status page by running this command:
curl http://localhost:8000/

What should I see?

The terminal prints the completed HTML response. You see Cloud Support Status in the heading and Operational in the status paragraph.

This result proves that the page content exists and the local server can return it on port 8000.

Final request not working?

Confirm that the background server still runs from mysub_dir. Check that your request uses port 8000.

Reopen index.html if either expected phrase is missing. Compare it with the complete reference above.

Help me verify my CloudShell status page and local server.

That baseline is now locked in. Your page exists, your server responds, and your terminal shows the expected status content.

Next, you will test the customer-reported endpoint and use process evidence to diagnose why that request behaves differently.

Reproduce the Port Incident

Your status page already responds inside AWS CloudShell on port 8000. That working baseline proves the page content can load.

The simulated customer expects the HTTP status page on TCP port 8080.

You will reproduce the exact request first. Linux process evidence will then explain the mismatch.

In this step, get ready to:
  • Reproduce the customer's failed request on port 8080.
  • Inspect the running server to capture its PID and launch command.
  • Compare the two endpoints to isolate the port mismatch.
Reproduce the customer failure

Fault reproduction preserves the customer's symptom as evidence. It gives every later conclusion a concrete starting point.

Before you run the request, do you expect the customer endpoint to return the status page or a connection failure?

  • Reproduce the customer request by running this command:
curl http://localhost:8080/

What should I see?

You'll see curl report a connection failure because no service is listening on port 8080. This is the intended incident evidence.

The failed request is expected. It proves the customer report is reproducible before you change the service.

Did Port 8080 Respond?

  • Check that the request URL ends with :8080/.
  • Leave any unexpected response unchanged so the next process check can identify its source.

Ask for help if your result differs: Help me understand why localhost port 8080 responded during this incident exercise.

Inspect the running server

A process list shows how the service actually started. The PID identifies the running process while the full command reveals its launch configuration.

Before you inspect the list, which part of the server command do you expect to explain the failed request?

  • Display every running process with full command details by running this command:
ps -ef

What Does This Command Show?

  • The ps -ef command shows every running process with its full command arguments.
  • The matching server row contains its PID and startup command.
  • Scan the output for the command containing python3 -m http.server.
  • Copy the PID from the matching row into the investigation checkpoint below.
  • Copy the full server command into the same investigation checkpoint.

Seeing Too Many Processes?

  • Scan the command text for http.server.
  • Match the row to the server command you launched earlier.

Use guided support if the matching row is still unclear: Help me identify the Python HTTP server in my ps output.

Confirm the healthy endpoint

A second successful request creates the contrast needed for diagnosis. The failed port and working port together isolate one changed variable.

Before you repeat the baseline request, do you expect the page content to remain healthy?

  • Repeat the working request by running this command:
curl http://localhost:8000/

What Proves the Root Cause?

You'll see HTML containing Cloud Support Status and Operational. The page still works on port 8000 after the request to port 8080 failed.

The page content is healthy. The active server uses its default port while the customer request targets a different port.

That is the diagnosis locked down. Your evidence now connects the failed customer endpoint to the server's active port.

Your diagnosis did not require a code change. The target index.html file therefore remains identical to the working baseline.

✔️ Awesome, I've got everything!

Your index.html already matches the working status page used in both requests.

ⓧ I'd like to double check the full code

<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Cloud Support Status</title>
  <style>
    body {
      margin: 0;
      min-height: 100vh;
      display: grid;
      place-items: center;
      background: #0f172a;
      color: #e2e8f0;
      font-family: Arial, sans-serif;
    }

    main {
      width: min(90%, 560px);
      padding: 2rem;
      border: 1px solid #334155;
      border-radius: 12px;
      background: #1e293b;
      box-shadow: 0 18px 45px rgba(0, 0, 0, 0.3);
    }

    h1 {
      margin-top: 0;
    }

    .status {
      display: inline-block;
      padding: 0.5rem 0.8rem;
      border-radius: 999px;
      background: #14532d;
      color: #dcfce7;
      font-weight: 700;
    }
  </style>
</head>
<body>
  <main>
    <h1>Cloud Support Status</h1>
    <p class="status">Operational</p>
    <p>The support status page is responding successfully.</p>
  </main>
</body>
</html>

Why Does the File Stay Unchanged?

The HTML already renders correctly on port 8000. The incident comes from the server's launch configuration, so no page edit belongs in this diagnosis.

Your incident now has a reproduced symptom and process-backed root cause. Next, you'll restore the service on the required port and document the resolution.

Restore Service and Document the Fix

Your investigation proved that the status page is healthy on port 8000. The failed customer request points to the mismatched port as the root cause.

You can now restore the expected endpoint without changing index.html. You will also turn your evidence into an incident report that explains the fix.

In this step, get ready to:
  • Reset the CloudShell session to stop the incorrect server process.
  • Restore the status page on port 8080 with a successful request.
  • Document the investigation in README.md.
Restart AWS CloudShell

Restarting AWS CloudShell stops the incorrect server process. Your files in the CloudShell home directory remain available.

  • Select Actions in the CloudShell toolbar.
  • Select Restart.
  • Select Restart in the confirmation dialog.

You will see a fresh Bash prompt when the new session is ready. The default-port server has now stopped.

  • Return to the existing mysub_dir directory by running this command:
cd mysub_dir

What does this command do?

The command returns your shell to the directory containing index.html. This ensures the new server publishes the existing status page.

Restart taking longer than expected?

Wait for the CloudShell prompt to return before entering another command. Confirm that the AWS Management Console still shows the same Region if your files seem to be missing.

Help me recover my CloudShell session after restarting it.

Correct the port mismatch

The Python HTTP server accepts an explicit port when it starts. Setting port 8080 aligns the running process with the endpoint in the customer ticket.

  • Start the existing status page on the required port by running this command:
python3 -m http.server 8080 &

What does this command do?

  • The http.server module serves files from mysub_dir.
  • The explicit port 8080 corrects the mismatch found during the investigation.
  • The & operator leaves the server running in the background.

Before you run the check, make a quick mental prediction about what the original customer endpoint returns now.

  • Test the original customer endpoint by running this command:
curl http://localhost:8080/

What does this command prove?

The curl request repeats the exact endpoint that failed earlier. A successful response proves that the corrected port restored the service.

You will see the page source in the terminal. It contains Cloud Support Status and Operational.

Still seeing a connection failure?

Check that the server command includes port 8080. Confirm that you ran it from mysub_dir.

Help me diagnose why my restored localhost service is still unavailable.

Write the incident report

An incident report preserves the reasoning behind a fix. This Markdown report separates the customer symptom from the evidence that established the root cause.

  • Open README.md in the CloudShell editor by running this command:
edit README.md

What does this command do?

The command opens a visual editor tab for README.md. The file becomes the permanent record of your diagnosis.

You will see an empty README.md editor tab. You can now build the report from the evidence you collected.

Editor tab not opening?

Confirm that the CloudShell prompt was ready before you entered the editor command. Check the CloudShell tabs for an existing README.md tab.

Help me open README.md in the AWS CloudShell editor.

  • Paste the scenario and investigation sections into the empty editor:
# Cloud Support Incident: Service Unreachable on Expected Port

## Scenario

A customer reported that the status page was unavailable at `http://localhost:8080/`.

## Symptom

The request to port 8080 failed even though the service had been started and the page content existed.

## Investigation

1. Requested the customer-reported endpoint with `curl http://localhost:8080/` and reproduced the connection failure.
2. Ran `ps -ef` and located the active `python3 -m http.server` process.
3. Requested `curl http://localhost:8000/` and received the expected `Cloud Support Status` page.
4. Compared the working and failing ports instead of changing the page content.

What do these sections capture?

  • The scenario records the endpoint that the customer expected to reach.
  • The symptom describes the visible failure without jumping to a conclusion.
  • The investigation preserves the request evidence and process evidence in order.
  • Save README.md with Ctrl+S.
  • Confirm that the report ends with the fourth investigation item.

Investigation list looks broken?

Check that each investigation item starts on its own line. Keep the item numbers in ascending order.

Help me fix the investigation section in my incident report.

  • Paste the root cause and validation sections below the investigation list:
## Root Cause

The Python HTTP server was launched without an explicit port, so it used port 8000. The customer-facing requirement expected the service on port 8080.

## Resolution

Restarted AWS CloudShell to stop the incorrectly launched process, returned to the project directory, and started the server with an explicit port:

```bash
python3 -m http.server 8080 &
```

## Validation

Ran:

```bash
curl http://localhost:8080/
```

The request returned the status page containing `Cloud Support Status` and `Operational`.

Why record the command evidence?

The root-cause section connects the failed request to the process configuration. The resolution and validation sections make the recovery reproducible.

  • Save README.md with Ctrl+S.
  • Confirm that the latest line names both visible status-page values.

Code blocks not displaying correctly?

Check that every fenced command begins and ends with three backticks. Keep the language label only on the opening fence.

Help me repair the command blocks in README.md.

  • Paste the customer update and reusable runbook below the validation section:
## Customer Update

The status page is available again on the expected endpoint. I reproduced the issue and found that the service was listening on port 8000 while the requested endpoint used port 8080. I restarted the service with the correct port and validated that the page now responds successfully. No customer action is required.

## Reusable Runbook

1. Reproduce the exact customer request.
2. Record the failure before making changes.
3. Confirm that the service process is running.
4. Compare the configured listening port with the requested port.
5. Restart the service with the corrected configuration.
6. Repeat the original request and document the result.

How does this close the incident?

The customer update explains the outcome in plain language. The runbook turns this incident into a repeatable troubleshooting process.

  • Save README.md with Ctrl+S.
  • Confirm that the report ends with six reusable runbook steps.

Report missing a section?

Compare the headings in your editor with the full-file reference below. Keep every section in the same order.

Help me find the missing section in my incident report.

✔️ Awesome, I've got everything!

Your report now preserves the complete troubleshooting story. Double-check that README.md is saved.

ⓧ I'd like to double check the full code

# Cloud Support Incident: Service Unreachable on Expected Port

## Scenario

A customer reported that the status page was unavailable at `http://localhost:8080/`.

## Symptom

The request to port 8080 failed even though the service had been started and the page content existed.

## Investigation

1. Requested the customer-reported endpoint with `curl http://localhost:8080/` and reproduced the connection failure.
2. Ran `ps -ef` and located the active `python3 -m http.server` process.
3. Requested `curl http://localhost:8000/` and received the expected `Cloud Support Status` page.
4. Compared the working and failing ports instead of changing the page content.

## Root Cause

The Python HTTP server was launched without an explicit port, so it used port 8000. The customer-facing requirement expected the service on port 8080.

## Resolution

Restarted AWS CloudShell to stop the incorrectly launched process, returned to the project directory, and started the server with an explicit port:

```bash
python3 -m http.server 8080 &
```

## Validation

Ran:

```bash
curl http://localhost:8080/
```

The request returned the status page containing `Cloud Support Status` and `Operational`.

## Customer Update

The status page is available again on the expected endpoint. I reproduced the issue and found that the service was listening on port 8000 while the requested endpoint used port 8080. I restarted the service with the correct port and validated that the page now responds successfully. No customer action is required.

## Reusable Runbook

1. Reproduce the exact customer request.
2. Record the failure before making changes.
3. Confirm that the service process is running.
4. Compare the configured listening port with the requested port.
5. Restart the service with the corrected configuration.
6. Repeat the original request and document the result.
  • Close the README.md editor tab.

Before the final check, make a quick mental prediction about whether the documented endpoint still returns the restored page.

  • Repeat the customer request by running this command:
curl http://localhost:8080/

What does the final check prove?

The repeated request confirms that the restored service remains available after you finish the report. It closes the same test loop that began with the connection failure.

You will see Cloud Support Status and Operational in the response. That closes the incident with a working endpoint and a complete evidence trail.

Final request stopped working?

Confirm that the background server process is still running on port 8080. Restart the corrected server from mysub_dir if the CloudShell session changed.

Help me restore the final localhost validation without changing my report.

Your service is restored on the customer endpoint. Next, you will publish the page and incident report in a public GitHub repository for review.

Publish Your Incident Portfolio

Your status page now responds on port 8080. Your incident report explains how process evidence exposed the mismatch.

A solved lab becomes career evidence when another person can review your troubleshooting story. In this step, you will publish the incident report to a public GitHub repository.

In this step, get ready to:
  • Create a public GitHub repository named cloud-support-incident.
  • Publish README.md plus index.html with clear commit messages.
  • Review the repository in an InPrivate window to prove public access.
Create the public repository

A public repository lets anyone on the internet review your files. Its visibility becomes part of your final verification.

Publishing can feel exposed because the link is open to everyone. Your two project files contain no AWS credentials.

  • Return to your verified GitHub account in Microsoft Edge.
  • Select New repository.
  • Choose your personal account as the repository owner.
  • Enter cloud-support-incident as the repository name.
  • Choose Public for the repository visibility.
  • Select the option to add a README.
  • Select Create repository.

Good progress. Your public portfolio shell now exists with a generated README on its first screen.

Repository creation blocked?

Confirm that your GitHub email is verified. If the repository name is already in use on your account, remove the older repository before trying again.

Help me troubleshoot creating this public GitHub repository.

Publish the incident files

The generated README gives the repository a landing page. Replacing it with your incident report puts the diagnosis first.

  • Switch back to the AWS CloudShell tab from earlier.
  • Select README.md in the CloudShell file tree.
  • Press Ctrl+A to select the report.
  • Press Ctrl+C to copy the report.

Your clipboard now holds the completed incident report from CloudShell.

  • Return to the cloud-support-incident repository.
  • Select README.md from the repository file list.
  • Select the pencil-shaped edit control in the file toolbar.
  • Press Ctrl+A inside the editor.
  • Press Ctrl+V to paste the incident report.
  • Select Preview.
  • Confirm that the preview includes the symptom, investigation, root cause, resolution, validation, customer update, and reusable runbook.

The preview now presents the full troubleshooting story before any implementation details.

  • Select Commit changes.
  • Enter Document the resolved port mismatch as the commit message.
  • Select Commit changes in the confirmation dialog.

Your repository page now renders the completed incident report as its introduction.

Report missing after the commit?

Check that you edited README.md in the cloud-support-incident repository. Reopen the file if the generated placeholder still appears.

Help me troubleshoot publishing my incident report to GitHub.

Your published report should match this complete file.

✔️ Awesome, I've got everything!

Your published report matches the completed CloudShell version.

ⓧ I'd like to double check the full code

# Cloud Support Incident: Service Unreachable on Expected Port

## Scenario

A customer reported that the status page was unavailable at `http://localhost:8080/`.

## Symptom

The request to port 8080 failed even though the service had been started and the page content existed.

## Investigation

1. Requested the customer-reported endpoint with `curl http://localhost:8080/` and reproduced the connection failure.
2. Ran `ps -ef` and located the active `python3 -m http.server` process.
3. Requested `curl http://localhost:8000/` and received the expected `Cloud Support Status` page.
4. Compared the working and failing ports instead of changing the page content.

## Root Cause

The Python HTTP server was launched without an explicit port, so it used port 8000. The customer-facing requirement expected the service on port 8080.

## Resolution

Restarted AWS CloudShell to stop the incorrectly launched process, returned to the project directory, and started the server with an explicit port:

```bash
python3 -m http.server 8080 &
```

## Validation

Ran:

```bash
curl http://localhost:8080/
```

The request returned the status page containing `Cloud Support Status` and `Operational`.

## Customer Update

The status page is available again on the expected endpoint. I reproduced the issue and found that the service was listening on port 8000 while the requested endpoint used port 8080. I restarted the service with the correct port and validated that the page now responds successfully. No customer action is required.

## Reusable Runbook

1. Reproduce the exact customer request.
2. Record the failure before making changes.
3. Confirm that the service process is running.
4. Compare the configured listening port with the requested port.
5. Restart the service with the corrected configuration.
6. Repeat the original request and document the result.

What should match?

This reference is the unchanged incident report from CloudShell. A matching public copy preserves the evidence behind your diagnosis.

The status-page source completes the portfolio by showing what the restored service returns.

  • Switch back to the AWS CloudShell tab.
  • Select index.html in the CloudShell file tree.
  • Press Ctrl+A to select the page source.
  • Press Ctrl+C to copy the page source.

Your clipboard now holds the exact status-page source served on port 8080.

  • Return to the GitHub repository.
  • Select Add file.
  • Select Create new file.
  • Enter index.html as the filename.
  • Press Ctrl+V inside the file editor.
  • Select Preview.
  • Confirm that the source begins with <!doctype html>.
  • Confirm that the source includes the heading Cloud Support Status.

The preview now contains the same source that produced your working localhost response.

  • Enter Add the operational status page as the commit message.
  • Select Commit changes.

That is the publishing work complete. Your repository now contains the incident report plus the status-page source.

Status page file missing?

Return to the repository file list after the commit. Check that the filename is exactly index.html.

Help me troubleshoot adding index.html to my GitHub repository.

Your published status-page source should match this complete file.

✔️ Awesome, I've got everything!

Your published page source matches the file served from CloudShell.

ⓧ I'd like to double check the full code

<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Cloud Support Status</title>
  <style>
    body {
      margin: 0;
      min-height: 100vh;
      display: grid;
      place-items: center;
      background: #0f172a;
      color: #e2e8f0;
      font-family: Arial, sans-serif;
    }

    main {
      width: min(90%, 560px);
      padding: 2rem;
      border: 1px solid #334155;
      border-radius: 12px;
      background: #1e293b;
      box-shadow: 0 18px 45px rgba(0, 0, 0, 0.3);
    }

    h1 {
      margin-top: 0;
    }

    .status {
      display: inline-block;
      padding: 0.5rem 0.8rem;
      border-radius: 999px;
      background: #14532d;
      color: #dcfce7;
      font-weight: 700;
    }
  </style>
</head>
<body>
  <main>
    <h1>Cloud Support Status</h1>
    <p class="status">Operational</p>
    <p>The support status page is responding successfully.</p>
  </main>
</body>
</html>

What should match?

This reference is the unchanged status-page source from CloudShell. A matching public copy connects the report to the service you restored.

Review the public evidence

An InPrivate window gives you a reviewer's view without the signed-in session. It proves that public access works independently of your account.

Before you test the link, do you expect both project files to be visible without your signed-in session?

  • Return to the signed-in GitHub window.
  • Press Ctrl+L to select the repository URL.
  • Press Ctrl+C to copy the repository URL.
  • Open an InPrivate window from Microsoft Edge's three-dot menu.
  • Press Ctrl+L to select the address bar.
  • Press Ctrl+V to paste the repository URL.
  • Press Enter to load the repository.

You will see the public repository without signing in. Its file list shows README.md plus index.html.

  • Review the first screen for the symptom, evidence, root cause, resolution, and customer update.
  • Select index.html from the public file list.
  • Confirm that the source includes Cloud Support Status plus Operational.
  • Inspect both files for AWS credentials.
  • Inspect both files for account identifiers.

Both files are publicly visible with no credentials or account identifiers. Your portfolio now proves the fault, diagnosis, restoration, and communication trail.

Public review not working?

Check that the repository visibility is Public. Confirm that both commits appear in the signed-in repository before copying its URL again.

Help me troubleshoot public access to my GitHub incident portfolio.

You have turned a localhost troubleshooting exercise into public evidence of cloud-support reasoning. A reviewer can now follow the incident from the original symptom to the validated resolution.

Secret mission

Repair a Missing Health-Check Endpoint

Your status page works on its required port, but an automated monitor requests a separate health-check path. Reproduce the missing-path failure, repair the endpoint, and prove that the process remains healthy.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep the lab available, pause the running server, or remove the CloudShell files and hide the public repository. This localhost-only project stays at $0 under AWS CloudShell pricing.

Resources you used:

  • CloudShell project files stored as mysub_dir/index.html, mysub_dir/README.md, and mysub_dir/health.html in the Region-specific home directory.
  • Background Python HTTP server process running on port 8080 in the current CloudShell session.
  • Public repository named cloud-support-incident on GitHub with README.md and index.html.

Keep everything running

Keeping everything requires no action. Choose this option if you want the status page files and public incident repository ready for more practice.

  • The mysub_dir folder remains in your Region-specific CloudShell home directory.
  • The background server stays active for the current CloudShell session.
  • The cloud-support-incident repository remains publicly available for review.
  • Your GitHub Free account remains active.
  • These project resources add no ongoing project cost.

Pause - I'll come back to this later

Pausing stops the active server process while preserving your CloudShell files and GitHub repository.

  • Select Actions in AWS CloudShell.
  • Select Restart.
  • Confirm Restart.
  • Leave the cloud-support-incident repository public for continued review.

The new CloudShell session has no active HTTP server. The mysub_dir folder and its three files remain available in the current Region.

Delete - I don't want to use this again

Use this option to remove the active CloudShell lab and hide the repository from public view. It makes sense to pause here because deleting the CloudShell home directory is permanent in the current Region.

  • Select Actions in AWS CloudShell.
  • Select Restart.
  • Confirm Restart.
  • Wait for the new CloudShell prompt.
  • Select Actions again.
  • Select Delete.
  • Enter delete in the confirmation field.
  • Confirm the deletion.

That clears the active lab from CloudShell. The server process and all three files are gone from that Region.

  • Return to the cloud-support-incident repository on GitHub.
  • Select Settings.
  • Scroll to Danger Zone.
  • Select Change repository visibility.
  • Acknowledge the effects of changing the repository visibility.
  • Select Make this repository private.

The repository is no longer accessible to everyone on the internet. Your GitHub Free account and private repository remain active.

Nice Work!

Nice Work!

You did it! You completed a cloud support incident in AWS CloudShell.

What you learned:

  • Built a visible HTTP status page that returned Cloud Support Status with an Operational status. Restored the same page on port 8080.
  • Practised fault reproduction with curl. Inspected Linux process evidence. Identified a port mismatch as the root cause.
  • Wrote a root-cause analysis backed by request evidence. Turned the resolution into a customer update. Captured the troubleshooting method in a reusable runbook. Published the case study in a public GitHub repository.
  • Secret Mission: Diagnosed a missing health.html path after observing an HTTP 404. Repaired the content-path issue. Confirmed that healthy returned in a successful response.

Ready to quiz yourself?