A fast “still pending” reply does not make the export fast

Eighty milliseconds after checking the report, the customer has an answer: still pending. The reply is quick. The thing they want is not ready.

This fictional Dispatch packet follows an export after its submission request ends. The first lesson examined slow status responses; this one examines a slow export. All observations are synthetic, and a paper investigation needs no telemetry installation.

The status request is not the export

Dispatch accepts the export and returns an identifier. The job waits in a queue until a worker takes it, reads source data, builds the report and stores the result. Separate requests later ask for status or download the file.

The status endpoint can be healthy and entirely truthful when it says “pending,” even when the customer has waited too long. Answering “Is it ready?” and making it ready are different work. Their clocks need to stay separate.

Keep the export identity, affected population and interval with you as you move across the map. Before using a fleet-wide chart, check what it includes. A fast reply for another account or operation does not explain this report.

Find the four minutes inside job-42’s timeline

Here are the observations for job-42, in UTC on one fictional day. The arithmetic assumes aligned clocks. Real-host comparisons must also account for clock uncertainty.

Acceptance to enqueue takes one second. The queue then holds the job for four minutes, and the worker stage takes thirty seconds. That is 271 seconds (four minutes and thirty-one seconds) from acceptance to ready. The 80-millisecond status request happens in the middle of the wait.

Four minutes in the queue tells us where to investigate, not why the delay happened. Perhaps workers were occupied, arrivals surged or a scheduling rule held this job back. The worker’s thirty seconds might also include waiting for reads and writes.

Ask for queue history and worker availability during this job’s wait. If workers were idle, was the job eligible and in their queue? If they were occupied, what kept them busy? The packet gives us those questions, not their answers.

A processing gap and a download gap need different checks

Two gaps remain, and they need different checks. More worker detail can divide the thirty-second stage into its parts. Beyond “ready,” we still do not know whether the intended user could obtain the correct file. Keep that missing download separate from the measured ready time.

The table puts a concrete observation beside each question. Writing “tracing” on the diagram would not supply those answers. Collect the detail at the point where the investigation needs it.

Keep the job and its attempt together

These three records are a minimal sequence from the packet:

14:00:00 export.accepted job=job-42 request=req-17
14:04:01 worker.started  job=job-42 attempt=attempt-1
14:04:31 export.ready    job=job-42 attempt=attempt-1

The job ID follows the export across requests and background work. The request ID identifies submission; the attempt ID identifies this particular processing attempt. If a retry creates a new attempt, combining the first attempt’s start with the second attempt’s finish would give a misleading duration.

Trace context carries execution relationships across boundaries so recorded spans and signals can connect. A job ID alone does not create a distributed trace. Nor does a trace ID replace the durable export identity used by the application.

Follow both job and attempt through the records on paper. If an event cannot be connected back to acceptance, you have found something the instrumentation needs to carry before installing a single component.

Ask for the observation that narrows this delay

Draw acceptance, queue, worker and ready state, with status and download as separate requests. Label what is timed, mark what is missing and write the first request for additional observations.

The status chart can now be fast and truthful without reassuring us about the report. The quick reply, the long queue wait and the unverified download all have distinct places on the map. The next observation should help follow that same export, not quietly substitute an easier question.