Skip to content
Prove It

Prove It

You get a customer ticket, a genuinely broken system, and no hint about which layer failed. Working out what to look at first is the skill.
Where should I begin?How this worksRepository

This is the whole idea

Section titled “This is the whole idea”

A customer writes to you. They tell you what they see, because that is all they know. Nobody tells you which layer broke.

CUSTOMER TICKET: dashboard unavailable since this morning

Account: Northwind Freight (enterprise) Impact: all users, complete outage Started: shortly after the 09:14 release

Nobody on our team can load the customer dashboard. It spins for a while and then times out. It was working fine yesterday afternoon and we have not changed anything on our side. We have a board review at 14:00 and this is the data we present from. Please treat as urgent.

Your job

  1. Prove what is actually failing before you name a cause.
  2. Restore service with the smallest correct change.
  3. Verify the customer's own workflow, not just that something responds.

Working notes

The service is expected on http://127.0.0.1:8100. The customer workflow is GET /customers. Runtime configuration lives in labs/docker/_stack/compose.override.yaml. After editing it, run tse apply to recreate the services, then tse check.

Look at the evidence

Real output, captured by running these commands against the broken system and checked against it on every build. It shows you what the evidence looks like. It cannot fix anything, and it will not tell you what is wrong.

Type a command you would reach for, or help.

Enter runs it. Shift and Enter start a new line. The up and down arrows walk back through what you have typed.

Try docker inspect on the database. It comes back healthy, and the customer still cannot load anything.

Learning to say exactly what that proves, and just as importantly what it does not, is the entire course.

Why this is different

Section titled “Why this is different”

Symptom-only tickets

Every other course names the topic before the exercise, which is the one thing a real ticket never does. Here the customer describes what they see, and deciding where to look is your job.

The grader shows its evidence

A check never just says pass or fail. It prints the assertion, the command it ran, and the raw output it evaluated, so being wrong teaches you something.

The writing is graded

Support is half communication. Customer updates and escalation notes are assessed work here, not an afterthought at the end of a lesson.

Built for difficult days

Uniform structure, a stated time cost on every exercise before you start, and a minimum viable day that still counts as progress.

Start in about two minutes

Section titled “Start in about two minutes”

Open the repository in a GitHub Codespace, wait for the container to build, and pick up your first ticket:

Terminal window
tse start docker/01

Investigate with ordinary tools. When you think you have fixed it:

Terminal window
tse check

Running locally instead needs Docker and Python 3.9 or newer. There is nothing to build, and tse doctor tells you what is missing, grouped by which track needs it.

The exercises

Section titled “The exercises”

Linux and CLI2 exercises

Docker3 exercises

Networking, DNS, TLS3 exercises

Kubernetes5 exercises

APIs4 exercises

SQL and PostgreSQL3 exercises

Observability2 exercises

Customer communication2 exercises

Mixed incidents2 exercises