# Trace (/academy/trace)



"The app is slow" is a weather report. A **trace** is a map.

Your demo is not one function. It is a traveler with a tracking number. The click hits the [API](/academy/api), waits on the [database](/academy/database), maybe calls Polar, then paints a page. Each hop is a *span* — a timed door on that one trip. The trace is the itinerary with a clock on every door.

You do not need a whole observability company for the idea. OpenTelemetry, a product APM, even `console.time` around the route the judge will click — same job. Follow one ticket. See which hallway ate 800ms.

**Not the other "trace"**

A [stack trace](/academy/stack-trace) is where a process *died*. A distributed trace is where a living request *lingered*. Same word. Opposite zoom. If the demo crashed, read the stack. If the demo lived and you hate waiting, pull a trace.

**Not a log either**

A [log](/academy/log) is one room's diary: everything the API process wrote tonight. Useful, local, incomplete. A trace stitches one request across rooms. When [latency](/academy/latency) hides in a handoff — frontend fine, backend fine, the tax service asleep — no single diary catches it.

**What you actually do**

At a hackathon, "checkout feels laggy" is a shrug. "Checkout spends 1.4s on Polar" is a Saturday you can still save. Instrument the path a stranger will click. Don't trace the whole universe.

When an [agent](/academy/agent) asks why it's slow, do not type "make it faster." Paste the span list, or say: "wrap this route in timings and name the `await` that is the hog." Agents guess at weather. They diagnose maps.

**What this unlocks**

Once you can follow one request, slowness stops being a vibe. It becomes a door with a clock on it. Open that door. Leave the rest of the line alone.