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, waits on the 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 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 is one room's diary: everything the API process wrote tonight. Useful, local, incomplete. A trace stitches one request across rooms. When 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 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.