Tags, and one case GitHub does not report

A rule can announce a tag as well as a release. This page covers what that means, and one situation where chronik cannot tell you anything — because it is never told.

A tag post waits ten minutes

Most teams push a tag and publish a release on it moments later. Announcing both immediately tells the same story twice: once thin, once complete, and the thin one first.

So a tag announcement waits about ten minutes, and when it is due chronik asks whether a release has appeared on that tag in the meantime. If one has, the tag post is dropped — the release post says everything it would have said. Your delivery log records that it happened and why, so a quiet channel is explainable rather than mysterious.

It works in the other order too: a release that arrived first suppresses a tag announcement that follows it.

Tags in one push

⚠️ When more than three tags go up in a single push, GitHub sends no notification for any of them.

This is a documented property of the GitHub platform, not something that went wrong on the way. The events are never created, so there is nothing for chronik to receive, nothing to retry, and nothing a later sweep could find and repair. From this side the push is indistinguishable from no push at all.

It matters most for a release train: tagging four repositories, or pushing four tags to one repository in a single git push --tags, is exactly the shape that triggers it.

What to do about it:

Push tags in smaller batches. Three or fewer per push are reported normally.
Or publish a release on the tags that matter. A release is a separate event and is always reported, however many tags went up with it.

There is nothing to switch on here and nothing to configure. chronik shows this warning at the moment you switch tag-watching on rather than leaving you to discover it.

Filtering which tags reach a channel

A repository that releases under several names — app-v1.2.0, api-v3.0.0 — can send each to its own channel. A rule takes a pattern like app-v* and lets only the matching ones through.

* is the wildcard and stands for any run of characters. There is no ?, and matching is case-sensitive: a filter of app-v* does not match APP-V1.2.0. An empty filter means everything, which is what every rule starts with.

A tag that does not match is passed over silently — no message, and nothing in the delivery log. On a repository with two filtered rules every release is passed over by one of them, so recording it would fill the log with entries that mean "working as configured".

A tag whose name marks it as a pre-release, such as 7.3.0-alpha or v2.0.0-rc.1, reaches a rule only when Include pre-releases is on, the same as a release marked as one on GitHub. The post then says it is a pre-release. The page on pre-releases lists which names count.

A repository that publishes tags and no releases — some projects never draft a release on GitHub — announces its versions as tags. When you pick such a repository for a new rule, Pushed tags is switched on for you, and the list of watched repositories marks it Tags only. If your rule on it watches releases alone, the list says so, because such a rule would never post.

Leaving tags out. A second field, Except tags matching, takes patterns a tag must not match, in the same form: * and nothing else, case-sensitive. Several patterns are separated by spaces — a tag name can never contain one. The filter above decides first, and the exception wins: with Include pre-releases on and *-alpha* left out, a channel gets betas and release candidates but no alphas.

A rule whose exception leaves out every tag the filter lets in could never post, so it cannot be saved. With *-beta* in both fields, or * as the exception and no filter, the form names the pattern that leaves out everything. The filter itself takes one pattern: typed with a space inside, it is refused, because no tag name can contain one.

If the filter is written for pre-releases, such as *-beta*, while Include pre-releases is off, the form warns you. Those tags stay out of the channel until the switch is on.

Checking a pattern before you save. Beneath the fields, the form lists the latest releases and tags of the repository and marks each one the rule would announce. For the others it names the first reason, such as a pattern that does not match or pre-releases being off, and the marks follow the form as you type. Where the names follow a scheme, like dates such as 2026.09.24.1, versions such as v0.3.0 or a package prefix such as api-v1.2.0, the form suggests a pattern for it and says how many of the names it matches. A click puts it into Only tags matching. The list appears once you choose Show the latest releases and tags, and the tags are read from GitHub at that moment. If that fails, the list shows the releases and says so.

On a repository you only watch — one you subscribed to without installing the app — chronik reads the tag list every hour once a rule on it watches tags. Commits are not reported for such a repository at all, so Commits pushed to a branch is not offered there.