## TL;DR

Time-to-publish reveals where your pipeline actually stalls: review, formatting, or scheduling.
You cannot fix a bottleneck you have not measured.
Applies to any content pipeline with more than one distribution channel.

## The query

```text
how to measure time-to-publish per channel
```

## Use this when

- You run a multi-channel content pipeline.
- Publishing feels slow but you do not know where it stalls.
- You want data before optimizing the pipeline.

## Not for

- You publish directly with no pipeline steps (time-to-publish is near zero by definition).
- You only care about total output, not speed (track output volume instead).
- The pipeline changes every week (stabilize it first, then measure).

## Steps

1. Log three timestamps per piece: content-ready, approved, and live on each channel.
   Expected output: A timestamp trail for every published piece.
2. Compute the gaps: ready-to-approved and approved-to-live, per channel.
   Expected output: Per-channel delay numbers showing where time goes.
3. Find the slowest stage and the slowest channel.
   Expected output: One named bottleneck, e.g. dev.to formatting or newsletter review.
4. Fix that one stage, re-measure for two weeks, and repeat.
   Expected output: A steadily shrinking time-to-publish on the slowest channel.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_wNEPzUtiEKZk2nRsy5d1QA