A latency investigation, written as a log

[Notice] Every IP, number and conversation in this piece is a teaching example (the structure and method are real and usable); this is not the record of an actual incident.

14:02 — Support forwards a ticket: three users in South-East Asia report "the site has been spinning since this afternoon". The first instinct is not to look at the server, it is to separate "who is slow": is it slow for us? No. Then it is most likely a path problem, not an outage.

14:10 — First round of baseline measurement from the server. Ping a representative node in the users' direction: latency normal, zero loss. Odd. But ping is five packets; it says nothing about peak behaviour. Note it as "normal in the off-peak window" and move on.

14:25 — Switch to MTR for the whole path, 100 packets. The output shows 23% loss at hop 6 and 0% at the last hop. My stomach drops and I nearly open a ticket saying "hop 6 is broken" — stop. Pull up the reading discipline: loss on an intermediate hop with a clean final hop is, most of the time, that router rate-limiting ICMP, not real loss. Real loss looks like "loss starting at some hop and continuing to the last one". False alarm — but those twenty seconds of self-correction are worth writing down: the tool supplies the numbers, the reading comes from your head.

15:40 — Realize the sampling window is wrong. The users said "since the afternoon", and their afternoon is our pre-evening-peak. Set up three windows: one now, one at 20:00, one at 22:00. Each round: MTR, 100 packets, archived, filename carries the timestamp.

20:15 — First evening-peak result: last-hop latency climbs from the ~80 ms of the off-peak window to ~220 ms, StDev widens visibly from hop 9 onward, and the last hop loses 4%. This one is real — degradation persisting from hop 9 to the last hop is the classic signature of congestion on the international egress segment.

20:40 — Open the ticket, submitted to the evidence standard: a one-sentence conclusion ("from the evening peak, sustained degradation after the hop-9 AS boundary, 4% loss at the final hop, three MTR archives attached"), plus the three raw MTR files with timestamps. No adjectives, no "very slow", no "severely impacted" — engineers want coordinates, not emotion.

Next day 11:00 — The datacenter replies: the routing policy for that direction's international egress was adjusted last week; evening-peak traffic was taking a more congested transit path, and it has been switched back. Retest three rounds: last-hop degradation falls back to within 1.3× the off-peak figure. Ticket closed, archive filed.

── Two reusable lessons ──
One, the time window is half of latency measurement: a "normal" off-peak window cannot rebut an "abnormal" peak window. Sample across the window the user is complaining about.
Two, a ticket's persuasiveness comes from structure: conclusion + criteria + raw archive + timestamps gets a problem handled faster than any adjective about urgency.

Write an ~800-word network latency investigation in log format (timestamped entries): the trigger is overseas users reporting the site got slow; the process covers three tools (ping, MTR, time-windowed sampling), one misread "intermediate hop loss" and its correction, and a final localization to evening-peak congestion on the international egress, followed by opening a ticket. Requirements: technically accurate detail, a sense of rhythm in how the timestamps advance, and two reusable lessons distilled at the end. Label the data as a teaching example at the top.