It syncs the full snap catalog every 15 minutes and records what’s new and what’s changed. I’ve been using it to keep an eye on what publishers are shipping, and I thought others might find it useful too.
What’s there so far:
New snaps: see what’s just landed in the store
Updated snaps: track version bumps and other changes
Browse by category: games, productivity, server, etc.
Publisher pages: see everything a particular publisher has shipped or updated
RSS feeds: available for everything: all changes, new only, updated only, per-snap, per-publisher, and per-category
Snap detail pages: screenshots, version history, metadata
It updates every 15 minutes and currently tracks over 10,000 snaps.
There’s no account or login; it’s just a read-only view of what’s happening in the store. No client-side JavaScript either (apart from the nav menu toggle). I even used the Canonical Vanilla framework!
I’d love to hear suggestions on how to improve it. Are there views or filters that would be useful? Information that’s missing? Things that look broken?
Any feedback is welcome; I’m actively working on it.
I was wondering if, in addition to the global search, it makes sense to have a small search bar/field for each individual category when you click into them?
Or another way to filter results within each individual category?
Some of those categories are very large; does it make sense to have a way to break them down more?
Great idea and thanks for the hard work supporting the community.
I think there might be an issue with version tracking, or rather lack of revision tracking. I just took a quick gander at the Firefox page and found this in the update history:
Firefox Update History
Change
Version
Date
updated
149.0-1 → 149.0.2-1
7 Apr 2026, 14:41 UTC
updated
149.0.2-1 → 149.0-1
7 Apr 2026, 14:37 UTC
updated
149.0-1 → 149.0.2-1
7 Apr 2026, 14:33 UTC
updated
149.0-1 → 149.0-1
26 Mar 2026, 13:49 UTC
updated
149.0-1 → 149.0-1
26 Mar 2026, 13:49 UTC
updated
148.0.2-1 → 149.0-1
24 Mar 2026, 13:25 UTC
updated
148.0.2-1 → 149.0-1
24 Mar 2026, 13:25 UTC
updated
148.0-1 → 148.0.2-1
10 Mar 2026, 15:57 UTC
updated
148.0-1 → 148.0.2-1
10 Mar 2026, 15:57 UTC
updated
148.0.2-1 → 148.0-1
10 Mar 2026, 15:45 UTC
updated
148.0.2-1 → 148.0-1
10 Mar 2026, 15:45 UTC
updated
148.0-1 → 148.0.2-1
10 Mar 2026, 15:41 UTC
updated
148.0-1 → 148.0.2-1
10 Mar 2026, 15:41 UTC
updated
148.0.2-1 → 148.0-1
10 Mar 2026, 15:37 UTC
updated
148.0.2-1 → 148.0-1
10 Mar 2026, 15:37 UTC
updated
148.0-1 → 148.0.2-1
10 Mar 2026, 15:25 UTC
updated
148.0-1 → 148.0.2-1
10 Mar 2026, 15:25 UTC
updated
148.0-1 → 148.0-1
26 Feb 2026, 15:25 UTC
updated
148.0-1 → 148.0-1
26 Feb 2026, 15:25 UTC
updated
148.0-1 → 148.0-1
26 Feb 2026, 15:21 UTC
There seem to be fluctuations of upgrades and almost immediate downgrades. But I believe that might be down to revisions. I think a snap can have the same version number but different revisions, because the former is dictated by upstream and the latter is a monotonic downstream revision counter. When the revision gets bumped for an older version, that counts as an update and, if the revision of a higher version was bumped before that, it appears as a downgrade.
I like this.
I had a go at something to achieve this.
If you go to any category, you’ll find a little search field. Type in there, and it will search only within that category. You can also link directly to those search results.
More feedback, the Firefox page still serving as convenient example. I have not found a way to switch channels, like on snapcraft.io/firefox; that button that currently says “latest/stable 149.0.2-1”. But, especially with Firefox, I sometimes get impatient and jump ahead by installing from latest/candidate, so it would be a very nice addition to see that revision history as well.
An interesting feature request. But this will be a bit more challenging to implement. Here’s where things stand and the key design question:
Current state: The sync uses the v1 search API, which returns only one version per snap (effectively the latest/stable). There’s zero channel awareness — no schema columns, no API params, no UI for it.
The core tension is sync cost vs. data richness. Here’s three possible approaches.
On-demand only — fetch channel-map from the v2 info API when someone visits /snap/{name}
Pros: Zero sync cost, shows current channel state immediately
Cons: No history per channel — you see what’s in candidate right now, but not when it landed or what came before
Sync all channels for all snaps — expand the 15-min cron to track every channel
Pros: Full history for every channel
Cons: ~4x API calls during sync (~15k snaps × 4 risk levels), might blow past CPU/time limits on the hosting platform
Hybrid — on-demand for current channel state + track channel history only for snaps that get visited (or a curated watchlist)
Pros: History where it matters, manageable sync cost
Cons: More complexity; cold snaps have no channel history
My instinct is 1 as a starting point — it directly answers the request (“I want to see what’s in latest/candidate for Firefox”) without the sync explosion. The v2 info API returns a channel-map with all tracks/risks/versions/revisions in a single call. We’d show a channel selector on the detail page with the current state of each channel.
Channel history tracking (2 or 3) could come later as a separate backlog item if there’s enough demand.
In the meantime, every page links to the official snapcraft.io store page, so for now, the current channel map is available officially.
Will put this on the backlog and figure out if it’s worth doing in the longer term. Thanks again.
Thanks for your thorough explanation. I did not know about the API limitations.
I think that’s effectively the simple solution to 1).
Item 2) sounds like a rabbit hole, because there may be other channels, which need to be discovered first. For instance, Firefox has esr/{stable,candidate,...} too. That alone might make it prohibitively complex and burdensome on the infrastructure, on top of that. Or is there a way to have some sort of caching, so if there was no change there is no traffic?
And 3) looks like a lot of state to keep track of. I wouldn’t want to do that, If I were in your shoes.
In summary, I think it may not be worth it, given the context. Implicitly, the latest/candidate channel history is somewhat ingrained in the stable history. Just the other day I could almost watch live, how my local FF snap transitioned from latest/candidate to latest/stable, because revision 8107 got promoted to the latter.
I also think that the 15 min interval might be too short. For me, personally, I think every hour, or even longer would suffice. Maybe even only once or twice per day would do? That should make 2) less daunting.
Hello friends.
