Why Your Release Shows Different Dates on Each DSP (and How to Fix It)
Your release went live on Spotify but not Apple Music, or shows different dates per store. The five causes: timezone rollouts, ingestion queues, metadata, territory rights and redeliveries.
When a release shows different dates or availability across DSPs, one of five things happened: a timezone-based rollout that is still in progress, a late delivery working through each store’s ingestion queue, inconsistent date metadata, territory restrictions in the deal terms, or a redelivery that has not propagated everywhere yet. All five are diagnosable, and most are preventable before the release ships.
This is one of the most common support questions in distribution, and it lands on the label’s desk from a confused artist at midnight. Here is what is actually happening under the hood.
Reason 1: midnight-local rollouts
Most DSPs turn a release live at midnight local time in each listener’s market. A global Friday release does not happen at one moment; it happens roughly 24 times, timezone by timezone, starting in New Zealand and ending in the Pacific. During that window, the release is genuinely live in Auckland and genuinely not live in Los Angeles, and both stores are behaving correctly.
A few platforms use a single global timestamp instead, which makes the mismatch look worse: one store is “already out” everywhere while another is still rolling out. If your artist is checking at 2 a.m. on release day, this is the most likely explanation, and it resolves itself within the day.
Reason 2: each DSP has its own ingestion pipeline
Delivery is not the same thing as availability. When a distributor delivers a release, each DSP ingests it into its own system, on its own schedule, with its own validation and review steps. If the release was delivered comfortably ahead of the release date, every store finishes processing in time and the dates line up. If it was delivered late, faster stores make the date and slower ones miss it, sometimes by hours, sometimes by days.
This is why lead time matters more than delivery speed. We covered the full pipeline in how long DDEX delivery takes.
Reason 3: inconsistent date metadata
A DDEX release message carries more than one date: the release date, the original release date (for catalog and re-releases), and per-deal start dates that control when each store, in each territory, may make the release available. When these fields disagree, different stores resolve the conflict differently. A re-released album with a wrong original release date can show 2019 on one store and 2026 on another, both read from the same delivery.
The fix is unglamorous: one canonical set of dates, validated before the release ships, not patched store by store afterwards.
Reason 4: territory rights and deal scope
If the deal terms exclude certain territories, the release is not late there; it is not coming. This is correct behavior that looks like a bug. It usually surfaces when catalog changes hands, when a license covers some regions and not others, or when a template deal was reused without checking its territory list.
Reason 5: updates and redeliveries propagate unevenly
Metadata corrections, artwork swaps and audio replacements are redeliveries, and each DSP applies them at its own pace. For a few days, part of the catalog reflects the update and part does not. The same applies to takedown-and-redeliver operations, which can also reset dates if the redelivery carries the wrong original release date.
How to make release dates line up
- Validate before shipping. Date conflicts, missing territory deals and metadata mismatches are all catchable pre-delivery. This is exactly what Agent Quality Control does at limbo/: every release is checked against Merlin and major-DSP requirements before it enters the delivery queue.
- Deliver early. One to four weeks of lead time absorbs every store’s ingestion variance and keeps you inside editorial and playlist-pitching windows.
- One canonical date set. Release date, original release date and deal start dates should be set once, consistently, in the source metadata.
- Know your deal scope. If territories are excluded on purpose, tell the artist before release day, not after the support ticket.
How limbo/ handles it
limbo/ is DDEX-native, with a per-DSP protocol map maintained on our side, so each store gets the message format and dates it expects. Quality control runs before delivery, not after the takedown, and a release that passes QC is delivered to stores in under 24 hours. When something does look wrong on a specific store, a human who knows your catalog picks it up, not a ticket bot.
