The update check cannot read releases (404 or 403 from the release source)

Symptom#

The Hub's update check warns every few minutes that it could not read releases from the release source. Typical messages:

• 404: "a private repository needs a token". The source answers as if the repository does not exist.
• 403: access refused, or the request was rate limited.
• Update jobs refused with 409 because the release is not signed.

Nothing else is usually affected: the API, database, backups and machines keep working. Only the "is a new version available" check fails.

Why it happens#

1. No token, or a token without read access. A private repository returns 404 to anyone who cannot see it, so a missing or under-privileged token looks like a wrong address.
2. Rate limiting. Anonymous or heavily shared tokens are limited quickly. The answer changes from 404 to 403 once the limit is hit.
3. Wrong saved configuration. The release source stored in the settings database (repository name, token reference) is stale or malformed.
4. Unsigned release. If unsigned updates are not allowed, a release without a signature is refused with 409. This is deliberate.

Steps#

1. Open the updates settings and note the repository the check reads. Confirm it is spelled exactly as the host shows it.
2. Confirm a token is set, has not expired, and has read access to that repository's releases (and nothing more).
3. Count the failures. If they began with 404 and later became 403, suspect a missing token first, then rate limiting.
4. If the token is right and the failures are 403, wait for the rate limit window to pass, and check whether the same token is used by other tools.
5. If the stored configuration looks wrong, correct it or clear the update settings and enter them again, then trigger one manual check.
6. If updates are refused as unsigned, sign the release. Only turn on "allow unsigned" if you have decided that is acceptable.
7. Watch the log for one check cycle. The warnings should stop and the latest release should appear.

Prevent a repeat#

• Use a dedicated read-only token for the update check, with a reminder before it expires.
• Raise a single problem record for a repeating warning rather than one ticket per day.
• Have the routine log review flag the same warning appearing more than a few times in 24 hours.