Here is a failure worth knowing about, because every part of it looks like it worked.
The traffic person builds Saturday, Sunday and Monday on Friday afternoon. The logs are correct. They are written into the folder the automation watches. The traffic system reports success. Monday morning, the advertiser asks why they did not hear their spot, and the as-run says nothing ran at all.
Nothing was broken. The logs simply arrived too late — and "too late" was Friday morning, not Saturday.
The rule
Most automation systems merge a traffic log into a day at the moment they build that day's hours. Once the day is built, a log arriving afterwards is not picked up. Nothing retries. Nothing warns.
This is not a fault in the automation. Building a day is a scheduled job that takes the inputs it finds at the time it runs, which is a perfectly reasonable way to work. It only becomes a problem when the traffic side assumes the deadline is *air time*, because it is not — the deadline is build time, and that can be a day or more earlier.
The two systems are each behaving correctly. The collision is in the workflow between them, which is exactly why nobody owns it and nothing reports it.
What it looks like when it happens
We measured this at our own station across fourteen days. The pattern is completely consistent:
| Day | Playlist built | Traffic log written | Spots aired |
|---|---|---|---|
| Sat 22nd | Fri 04:59 | Fri 15:21 | 0 |
| Sun 23rd | Fri 04:59 | Fri 15:21 | 0 |
| Mon 24th | Sat 05:30 | Sat 04:32 | 6 |
| Tue 25th | Sat 05:30 | Mon 17:35 | 0 |
Monday survived by luck. The automation happened to rebuild that day at 05:30, which was after the log landed at 04:32. Saturday and Sunday were built at 04:59 on Friday morning and never rebuilt, so the logs that arrived that afternoon — ten hours later — were ignored.
Tuesday is the clearest case. Its log was delivered the evening before it aired, which feels early. It was three days late.
Why it gets misdiagnosed
Every instinct points somewhere else, and we chased all of these first:
- The clocks. They were fine. Break markers were present and correctly configured on the weekend clocks.
- The log file. Well-formed, correct row count, in the right place.
- The as-run parser. It matched the source file exactly — the spots really were absent, not misread.
The tell is subtle. In a playlist file, a break marker appears only on a merged spot line. It is the inserted spot's own category, not a standing placeholder sitting in the clock. So a day showing zero markers means *the merge never ran* — not that the clock was missing breaks.
Read it the other way and you spend a day hunting a clock fault that does not exist. We did.
The fix is timing, and the repair is a rebuild
Deliver before the automation builds the day. That is the whole of the fix, and it is why "you have not built next week's logs yet" is urgent rather than administrative. The window in which a log can still land closes when the day is built, not when it airs.
If a day has already been built without its log, the repair is to rebuild that day in the automation with the log now present. We confirmed this from the other direction on purpose: four days that showed zero markers were rebuilt after their logs arrived, and every one then carried exactly the spots that had been sent.
What Cartwright does about it
This is the part we changed after finding it, because a system that delivers correctly and says nothing for three days is not good enough.
Cartwright compares two timestamps for every day still ahead: when the automation last built that day, and when the traffic log was delivered. From those it says one of four things.
| State | Meaning |
|---|---|
| Not built yet | Fine. This is what delivering early buys you. |
| Built, log delivered before | Fine. It will merge. |
| Built, log delivered after | The window closed. These spots will not run. |
| Built, never delivered | No log for a day that is already scheduled. |
The last two appear on the Dashboard above everything else, including today — because a day already on air cannot be saved, and these still can.
There is a second tile for the problem underneath it: days inside a live flight with no log built at all. That one is computed from the flights rather than from the logs, for the obvious reason that a log which does not exist cannot report its own absence.
The short version
If spots are not airing and everything looks correct, check when the day was built against when the log was delivered. If the build came first, you have found it.
Deliver early. Days ahead, not hours.
---
*Cartwright is radio traffic, CRM and billing software for local stations — what it does, or download it and try it free for 30 days. More on reconciling what actually aired in Spots you owe back.*