On one day in July, the request we'd made every morning for over three months stopped answering. We read that as an ending. It wasn't — it was a locked door in a building that was still standing — and this report very nearly went out saying otherwise.
We first told this story on 5 July 2026 as a freeze: a "trending" chart that had not moved because nobody was maintaining it. That reading held for another seven weeks. We captured the same endpoint once a day, every day, from Apr 13, 2026 through Aug 22, 2026 — 129 distinct days, 108 individual captures. Then, on our very next scheduled run, the request that had returned a chart every morning for over three months returned a 404 instead.
The conclusion we nearly published
The first draft of this report stopped there and drew the obvious-looking conclusion: Suno had deleted the endpoint outright, our archive was sealed for good, and /pulse would never gain another reading. That draft was written, reviewed, and queued to ship. All three claims were wrong, and the error was ours rather than a limit of the data — the disproving test was one request away and we did not run it. /api/trending was never the whole story; it was an alias for a playlist object, and that object has its own address: /api/playlist/1190bf92-…. We tested the alias, got a 404, and stopped. We never tested the object underneath it.
To be exact about what did and did not happen: that draft was caught before deployment, so the false version was never served to anyone. We are describing a near miss, not a retraction. We are writing it up anyway, because the interesting part is not that we avoided the mistake — it is how ordinary the mistake was. A 404 on the endpoint you have queried every morning for three months reads as an ending. It took deliberately distrusting our own conclusion to spend one more request on it.
When we finally did, the same day, it answered 200 — the same "Explore" playlist, still public, at the address it always had. Nothing about our access had been revoked; only the shortcut into it was gone.
2
Distinct non-empty rosters this endpoint has ever returned, across all 108 captures we took of it through the alias route (a same-day fetch glitch produced 5 empty captures on 2026-04-20; we don't count those as a third roster). Not two rosters per week, or per month — two, total, in 129 days of daily photography. That is the measurement that turned "frozen" into "abandoned" — a reading about membership, which is still true, and unrelated to whether the door into it stays open.
The window Suno removed the door
Our cron job runs once a day. It cannot pin the exact minute the route went away, but it bracketed it tightly: the last successful capture through the alias landed Aug 22, 2026, 41 clips, complete. The next scheduled run, one day later, failed outright. We confirmed it was not our own request that broke: a live, out-of-band probe on 2026-07-27 hit /api/trending and got back a Cloudflare-rendered HTML "Not Found" page — not the API's own JSON error shape, meaning the request never reached the application at all. The same probe, same client, same moment, hit the fossil's own playlist address plus two real editorial-shelf playlist endpoints and got clean 200s from all three. That rules out a block, a rate limit, or a network fault on our end. The route is gone. The object it pointed at answered normally the entire time.
Top-10 turnover · daily
The membership froze years ago. The numbers didn't.
Being wrong about "deleted" made us re-check something we'd been asserting since the first freeze report without ever testing it directly: whether this object was, underneath the stale roster, actually static. It isn't. Comparing the live playlist against our own last alias-route capture, every one of the 41 clips we track was still present — membership can only shrink here, by owner deletion, never grow — but 5 of those 41 clips had gained plays in the days between, for a net of +49 across the group. Suno's own num_total_results field still stale-reports 49, one more than the 48 entries actually there. The accurate model was never "a static blob served fresh." It is a frozen 2024 playlist row, joined against clip rows that are still live underneath it.
What the alias route actually was
The trending feed was never just a leaderboard to us — it was also, briefly and by accident, a source of remix lineage. Suno's serializer redacts the UUIDs that link a clip to what it was remixed, edited, or covered from on every endpoint we've checked except this one, and only for a while. We harvested 102 lineage edges through that gap before Suno closed it — and every one of those edges carries the identical discovery timestamp of 2026-05-10. Not a trickle over months; one instant.
Getting the route's fate right let us finally answer a question we'd never separated out: was the leak in the object, or in the alias? We fetched the same fossil playlist through its surviving direct address and counted the same fields. The answer is the alias: read through /api/playlist/… today, concat_history is 0 real, 88 redacted; edited_clip_id is 0 of 6; history is 0 of 2; only cover_clip_id still carries anything real, 3 of 4. Historically, through the alias, every one of those pointers came back real. The sealed remix archive built from that harvest is sealed for the right reason after all — but the reason is that the leaky serializer path is gone, not that the data behind it vanished. It is sitting right there, redacted, one request away.
The monitor that couldn't fail
One more finding, less about Suno than about us. Our own weekly schema-drift canary ran after the alias route was already gone and reported a clean "ok" — it treats an unreachable endpoint as a low-severity, non-blocking event on the reasoning that the daily collector would catch a real outage first. Once the alias 404'd, that reasoning stopped holding: the canary was, for at least one run, watching a route that resolved to nothing and calling it healthy. We are noting it here in the interest of the same honesty we ask of Suno's own discovery surface — a monitor that cannot fail is not a monitor. It has since been repointed at the objects we actually depend on.
What it means
We do not know why Suno removed the alias, or whether it was deliberate cleanup or an incidental casualty of other backend work. We hold the record on both sides of it now: 129 days of daily photography through the alias, the exact day it went dark, and the object it pointed at — still public, still redacting, still ticking — read directly ever since. Suno's real discovery surface — the editorial shelves we snapshot daily at /charts — is untouched by any of this; it was never the same system. This page, the fossil-watch at /pulse, and the preserved leaderboard at /trending all describe an object a platform stopped curating in 2024 and stopped linking to in 2026 — not one it deleted. We are, as far as we know, the only ones who noticed either event, and the only ones who got the second one wrong first and said so.