# Check every GitHub release actually shipped a Docker image

> A board that lines up the versions you tagged against the images your registry actually has, so a quiet build failure never reaches a customer.

- Workflow type: app
- Services: Docker Hub, GitHub
- Categories: Engineering, Operations
- Published: 2026-08-21

## What it does

- Pairs each code repository with its image repository once, then shows your latest releases side by side with the image tags the registry actually has.
- Flags the gap that actually hurts: a version you released with no published image behind it. Problem rows sort to the top of the board.
- Also catches images with no release behind them, and repositories where the newest image is older than the newest release. Names like v2.3.0 and 2.3.0 are treated as the same version, so you do not get false alarms.
- File a build gap issue in one click, or hand the row to a background helper that investigates why the image never arrived and writes the explanation into the board.

## What you'll need

- A GitHub account with access to the repositories you cut releases from.
- A Docker Hub account, plus the organization or user namespace your images are published under.
- A few minutes on first load to confirm which code repository maps to which image repository. The app suggests the obvious pairs for you.

## Prompt

I want an app that tells me whether every version we tagged on GitHub actually made it into Docker Hub as a published image. Our build pipeline sometimes fails quietly, and today we only find out when someone tries to pull a version that was never pushed. The app is a reconciliation board I open right after a release goes out, before we tell customers the version is available.

Pairings come first. Let me pair each GitHub repository with its Docker Hub repository once, and save those pairings in the app so they persist between visits. On first load, suggest matches automatically based on name similarity: pull candidate GitHub repositories with List Organization Repositories (and Get a Repository when I point at a specific one), pull candidate Docker Hub repositories with List Repositories in a Namespace, then propose the obvious pairs for me to confirm. Every pairing stays editable, so I can add, change or remove one at any time.

The main view is one row per pairing. On the left the row shows the most recent GitHub releases from List Releases, with the newest full release identified by Get Latest Release. On the right it shows the image tags Docker Hub actually has from List Repository Tags, including when each tag was last pushed. Reading a row left to right should immediately answer one question: did this version ship?

Give every row a clear status. Matched means each release has a corresponding image tag. Missing image means a release exists with no matching tag, and that is the one that bites us, so make it the loudest state and sort it to the top of the board. Untracked image means a tag exists with no release behind it. Lagging means the newest image is older than the newest release. Always show the specific versions involved in a status, not just a colour.

Be smart about naming, because false alarms will make me stop trusting this board. Treat v2.3.0 and 2.3.0 as the same version. Ignore architecture and variant suffixes such as -amd64, -arm64 and -alpine, and ignore a trailing build number, when deciding whether a release and a tag refer to the same version. Make this normalization rule explicit in the interface and let me configure it, so I can match how we actually name things. Exclude draft releases and prereleases from the missing image check by default, since those often skip publishing on purpose, with a setting to include them.

From a problem row I need two actions. Recheck re-runs the comparison live for that pairing, re-reading the tag list and confirming the exact expected tag with Check Repository Tag, so I can see whether a late build finally landed. File a build gap issue opens an issue on the paired GitHub repository with Create an Issue, and the issue body must carry the version, the exact tag name we expected to find, and what was actually found in the registry.

Add an Investigate this gap button on problem rows that starts a background agent. The agent reads the release itself with Get Release by Tag, pulls the full tag list with List Repository Tags, inspects a specific nearby tag with Read Repository Tag when that helps, studies how this repository normally names its tags, and reviews recent registry activity with List Audit Log Events for the namespace to see whether anything was pushed around the time of the release. From that it works out the likely reason the image is missing: the publish job never fired, the push failed, the image went out under a different tag name, or it was pushed and later deleted. One known cause worth checking for is that events triggered by the default GitHub token do not start a new workflow run, so a release created by automation can silently never fire the publish job.

The agent writes a short diagnosis back into the app, stored against that row so it is still there when I come back later, along with when it ran. After writing the diagnosis it offers to open the GitHub issue with that explanation already written up, so I can file a well explained issue in one click instead of retyping the findings.

I mainly open this right after a release goes out and before we tell customers a version is available. So the board should lead with the problem rows, and when everything matched it should make the all clear obvious at a glance.

## How to customize

- Adjust the version matching rules, such as which name suffixes to ignore, so they fit the way your team tags images.
- Decide whether draft releases and prereleases count toward the missing image check. They are left out by default.
- Choose how many recent releases and tags each row shows, and how the board sorts rows.

## FAQ

### Why would a release have no image behind it?

Usually the publishing step failed quietly. A common cause is that a release created by automation does not always start a new build run, so the job that pushes the image never fires at all. Nothing looks wrong on the code side, which is exactly why it goes unnoticed until someone tries to pull the version.

### Will this work with private repositories and private images?

Yes. The board shows whatever the connected accounts can already see, so private repositories and private images are included as long as your login has access to them.

### Does it change anything in my registry?

No. The board only reads your releases and image tags. The only thing it ever writes is an issue on your code repository, and only when you choose to file one.

### We name our images differently from our releases. Will it just show false alarms?

The matching rules are yours to set. Out of the box a leading v is ignored, so v2.3.0 and 2.3.0 count as the same version, and common suffixes like architecture names are ignored too. You can change the rules until the board matches your naming.

### Does it check on a schedule or send alerts?

Neither. This is a board you open, typically right after a release goes out and before you tell customers the version is available. Each row also has a Recheck button that re-runs the comparison live if you are waiting on a build to land.

Use this prompt in General Input: https://www.generalinput.com/prompts/check-every-github-release-actually-shipped-a-docker-image