Time to First Fix (TTFF)
TTFF measures how long it takes, from the moment a container or booking is added, until Dockflow has its first tracking data. It is the "cold start" metric - how quickly tracking begins.
TTFF = AVG(first_fix − created_at)
Target: 8 hours | Lower is better
What it measures
TTFF indicates how quickly tracking data starts arriving after a container is added. A lower value means faster initial visibility.
| Field | Meaning |
|---|---|
created_at | When the tracking job was created (container added via API, upload, or manual entry) |
first_fix | When the first tracking data was received and stored |
TTFF measures the gap between the two.
How it works
When a container is added:
- Created - Dockflow creates a tracking job (
created_at). - Queued - Dockflow queries carrier systems.
- First fix - the first data point arrives and is stored (
first_fix).
TTFF is the time between step 1 and step 3.
Exclusions
TTFF deliberately drops rows where the number would be misleading:
| Exclusion | Rule | Why |
|---|---|---|
| Backfilled data | first_fix < created_at | A first fix that predates creation is a historical import, not a real cold-start measurement. |
| Inactive bookings | booking-only entry with TTFF > 24h | A booking that took more than a day for its first fix was almost certainly not yet active when it was created; counting it would inflate the metric. Bookings already linked to a container are kept. |
| No first fix yet | first_fix is null | Nothing to measure until the first data arrives. |
Like Confirmation Delay, TTFF does not filter on whether the tradeflow is still active - the question "how fast did tracking start" is answered once, at creation time, and does not change because the tradeflow later closed.
Outliers
Any container with TTFF above 80 hours (10 × the 8h target) is held out of the average and reported separately as an outlier count, so a few very slow cold-starts cannot distort the headline number.
Status bands
| Status | Band | Meaning |
|---|---|---|
| On Target | ≤ 8 h | Data arriving quickly after add |
| Warning | 8 - 12 h | Some delay in initial data |
| Critical | > 12 h | Significant delay; may indicate reference or visibility issues |
What affects TTFF
| Factor | Effect |
|---|---|
| Carrier API availability | Some carriers surface new containers faster than others |
| Container visibility | A new booking may not yet be visible in the carrier system |
| Reference correctness | A wrong or not-yet-linked booking/BL reference delays the first fix |
| Processing queue | High-volume periods can add wait time |
Drill-down view
Click "View details" to list individual containers sorted by TTFF:
- Worst first: containers that took longest to get first data.
- Best first: containers that received data fastest.
Export to CSV, up to 1,000 rows.
Troubleshooting high TTFF
Possible causes
- Container not yet visible in the carrier system
- Booking reference not yet linked to a container
- Carrier API delays
What to do
- Allow 24-48 hours for brand-new bookings before treating a high value as a fault.
- Verify the booking / BL references are correct.
- Check the carrier portal directly to compare.