Cal.com's repo was committed to yesterday. The newest version you can install is six months old.

I run my own booking software. Not because it is cheaper — count the hours and it is not — but because I am building a product that will ask small businesses to trust it with their invoices and their card payments, and I would rather learn what that trust costs on my own infrastructure than on theirs.

Two weeks ago I went to upgrade it. There was no upgrade. There was also no error, no warning, and nothing in any dashboard suggesting anything was wrong. Everything I was monitoring said the project was in excellent health, and everything I was monitoring was looking at the wrong thing.

The numbers

Cal.com is the open-source scheduling tool most people reach for when they do not want to pay for Calendly. In 2026 it renamed itself to Cal.diy and relicensed from AGPL to MIT — a move from one of the most restrictive open-source licences to nearly the least. That is a project giving away more, not less.

Here is what I found when I actually looked, on 2 September 2026:

• The repository was last committed to on 1 September 2026. Yesterday.
• It has 48,101 stars and is not archived.
• Its most recent release is v6.2.0, published 1 March 2026 — 185 days earlier.
• The most recent container image is from 2 March 2026. 184 days.

On its own, six months between releases might mean nothing. Plenty of good software ships twice a year. So I pulled every version tag the project has ever published — 324 of them across 265 distinct release days going back to January 2023 — and worked out what normal looked like.

# Every published version tag, newest first. Verified 2026-09-02.
REPO=calcom/cal.com
curl -s "https://hub.docker.com/v2/repositories/$REPO/tags?page_size=100&ordering=last_updated"   | jq -r '.results[] | "(.name)  (.last_updated[:10])"'

  v6.2.0-arm  2026-03-02   <- newest
  latest      2026-03-02
  v6.2.0      2026-03-02
  v6.1.16     2026-02-12
  v6.1.15     2026-02-12
  v6.1.14     2026-02-10
  v6.1.13     2026-02-09

Across the last thirty release days, the **median gap between releases was 1.5 days**. In three and a half years the longest the project had ever gone without publishing was 80 days.

The current gap is 184 days. That is more than twice the longest pause in its entire history, during a period when the repository has been committed to almost every day.

Why nothing told me

This is the part worth your attention, because it is not really about scheduling software.

I assumed a stopped project would announce itself. It does not. It is worse than that: **every signal most of us monitor is a signal about the repository, and the repository is not the thing you install.**

• Stars go up. Ours went up while I was writing this.
• Commits land daily, so any "last activity" check passes.
• The website looks maintained, because it is.
• The `latest` tag still exists and still pulls, so nothing 404s and no alert fires.

That last one is the trap, and it took me longest to see. I had assumed that if something went wrong I would get an error. But `latest` is not a promise about time — it is just a label somebody last moved in March. It will keep resolving, keep pulling, and keep working forever. An image that has stopped being updated and an image that is simply stable are byte-for-byte indistinguishable from the outside.

A container-update watcher tells you when a new image appears. It cannot tell you that no new image is ever going to appear again. Both of those look like silence.

What I am not saying

I want to be careful here, because this is where it would be easy to be unfair.

I am not claiming the project is abandoned, that anyone acted in bad faith, or that there is a story behind it. A six-month gap with daily commits is at least as consistent with a large release in progress as with anything else. Maintainers owe me nothing — I have paid them nothing. Publishing container images for strangers is unglamorous work, and stopping is an entirely legitimate choice that nobody is obliged to announce.

What I am claiming is narrower, and I think more useful: **I depend on the artefact, not the repository, and I was monitoring the repository.** That was my mistake, not theirs, and if you self-host anything you have probably made the same one.

How to check your own stack in five minutes

Take the images you actually run and ask when each was built — not when its repository was last committed to. On a Docker host:

# Every image in use, and the date it was built. Oldest first.
docker ps --format '{{.Image}}' | sort -u | while read -r img; do
  printf '%-50s %s\n' "$img" \
    "$(docker inspect "$img" --format '{{.Created}}' 2>/dev/null | cut -c1-10)"
done | sort -k2

For anything more than six months old, go to the registry — not GitHub — and check whether a newer tag exists at all. Then answer one question per service:

What I did

I stayed. That is the boring answer and it is the right one.

The version I run works. MIT lets me keep running and modifying it indefinitely. Migrating a live booking funnel onto a hosted product mid-build costs more today than the risk I am carrying, and that risk is bounded: the worst case is frozen software that does one job correctly.

What changed is what I watch, and what I wrote down. The check now runs against the registry rather than the repository, and the runbook has a sentence in it that would have saved me most of a day:

The general version

Every piece of infrastructure you did not write has an end date you will not be told about. There is no email. The project does not feel dead — this one has never looked healthier on the metrics most people check. You go to upgrade one ordinary Tuesday and find the newest door is six months behind you.

The defence is not to stop self-hosting. I am not going to. The whole reason I run my own mail, calendar, database and proxy is that I would rather meet a failure at three in the morning on my own box than have a customer describe it to me on theirs.

The defence is to know, for every dependency, exactly what would have to be true to keep running it for five more years with no upstream at all — and to be honest about whether that is already the situation you are in.

For this one, it already was. I just had not checked.

Every figure above was pulled on 2 September 2026 and the commands to reproduce them are in the article. If they have moved since, the method still works.