Skip to content
Module
Module 6 of 6Lesson 1 of 3~13 min

Qualifying an incident layer by layer

When a page goes blank or slows down, a vague alert pulls in the whole team without helping. This lesson teaches you to link a symptom to the likely layer of the product, gather the evidence that matters and write a clear incident report, so developers can act quickly and in the right place.

Take this lesson: your first course is freeSee the full syllabus

Lesson objective

By the end of this lesson, you will be able to attach a symptom (slowness, blank page, error, stale data, action with no effect) to a likely layer of the journey, gather the useful evidence and write a report that lets the team act fast.

Topics covered

  • incident triage
  • bug report
  • incident diagnosis
  • technical support
  • Product Manager

Where it fits

Diagnose and map your product

How do I use all of this to qualify an incident and describe my own product?

Lessons in this module

  1. Qualifying an incident layer by layer (this lesson)
  2. Drawing a request's journey through your product
  3. Exit kit and application plan

What you will learn in this module

This lesson is part of the course Explain how a web product works, from browser to server

  • Explain how responsibilities are split between browser, frontend, backend, API, database and third-party services, and place where a business rule must run.
  • Explain the role of a CDN and of caches (browser, CDN, server) and anticipate their effects on speed, data freshness and releases.
  • Tell apart local, preview, staging and production environments, and say what changes from one to another (configuration, data, secrets).
  • Place a symptom (slowness, blank page, error, stale data) in the right layer and ask the technical team precise questions.
  • Produce the annotated diagram of a request's journey through your own product and have it validated by a developer.

Related courses