Your error tracker could shut down overnight

Two shutdown notices made the rounds this month. DNS-O-Matic, a free service that forwards dynamic IP updates to your DNS providers, gave its users 30 days. Autistici/Inventati, an activist collective that ran mail, blogs, and websites for 25 years, announced it is shutting down entirely after pressure its members could no longer absorb. The Hacker News thread about the second one reached 607 points, and plenty of the comments were people asking what happens to everyone who depended on it.

Different causes, same shape. Something you never think about stopped existing, and the people relying on it had to scramble. This post is about one dependency in particular: your error tracker. It has an uncomfortable property that most tools on your stack do not have.

You open it when everything is already broken

You read your error tracker during the worst hour of your week. A release is failing, a webhook is quietly dropping payments, checkout throws for half your users. At that exact moment, your ability to debug depends on a second service staying up, staying funded, and keeping your history.

If that service disappears, you lose the open issues, the grouping fingerprints, and the trend line that told you whether tonight's errors are new or a slow leak from August. You lose them at the moment you need them most, and you lose them on someone else's timetable.

The Autistici/Inventati announcement is the blunt version of this. Twenty-five years of operation ended in one post, and the announcement itself warns that the domain could become unreachable before users finish backing up. Free infrastructure runs on someone's budget and legal safety. When those run out, the schedule is theirs, not yours. DNS-O-Matic is the mundane version of the same event: a free tool, a 30 day notice, thousands of router configs quietly going stale.

Three questions that stress-test the dependency

1. What breaks tonight? If the tracker vanished mid-incident, which runbook steps die with it? Think export access, retention, and the issue history your team searches at 3am.
2. Who carries the organization risk? Price is the wrong signal here. Both tools above were free. The question worth asking is how many of your dependencies rest on one team's funding, health, and legal exposure.
3. What does self-hosting cost in practice? Most takes on this cheat. They count the install command and skip the patching, upgrades, backups, and the disk that fills up during your busiest week.

The self-hosted options and their real costs

Sentry's official self-hosted distribution is the first thing people find when they search for an alternative. The project describes itself as feature-complete and packaged "for low-volume deployments and proofs-of-concept". Its compose file brings up ClickHouse, Snuba, Redis, a symbolicator, a relay, and cron containers alongside the main app. It runs. It is also a lot of moving parts for a small team's VPS, and 9.6k stars on GitHub do not change the ops bill.

GlitchTip is the middle option. It is open source, compatible with Sentry's client SDKs, and its own site positions it as easier to run, with hosted plans if you would rather not run anything at all. For teams that want the Sentry wire format without the container herd, this is the pragmatic pick.

Then there is our own take, TrapFall. It is a single Rust binary with SQLite by default, a Docker image of 5.75MB, and it speaks the Sentry envelope protocol, so your existing SDKs keep working after a DSN swap. We covered the spec details, including which envelope types are supported, in our first post. The honest status: v0.3.0 shipped on September 3, the repository has 8 stars, and our own production instance is not live yet. We are deploying it into our own fleet next, and we will write about what breaks.

That is a menu, not a ranking. The right answer depends on the three questions above.

Where managed still wins

A team with no ops capacity should not run its own error tracker. Self-hosting moves the dependency from a vendor to you, and if nobody owns patching and backups, you have built a quieter outage that surfaces at the worst time. Managed services also carry features a small binary will not chase: session replay, profiling, source-map-backed symbolication at scale. TrapFall does not support replay or profiling yet. If those are load-bearing for you, staying on a cloud plan is a legitimate answer, not a failure.

Self-hosting also does not fix the failure mode where you are the problem. If your only copy of incident history lives on one VPS with no backups, a dead disk does what a dead vendor does, just with worse support.

What we would do next

Keep your current tracker. Pick one internal tool or side project, point its DSN at a self-hosted instance, and let it soak for a month. Note what you miss, what you end up exporting by hand, and how much maintenance the box really needs. After 30 days you will have a tested answer to "what breaks tonight" instead of a guess.

Run the three questions on your other dependencies too. Error tracking has the sharpest timing, but the pattern is everywhere: feed readers, DNS dashboards, status pages. The Autistici/Inventati collective gave 25 years and still could not promise a graceful exit. Nobody else can either.

TrapFall covers the error half of our DevOps loop. The review half is cora-code, which we covered in how cora-code detects logic errors before merge.

References

1. Autistici/Inventati, "A/I shuts down. Stay human." keepitfree.ai
2. Hacker News discussion, September 2026: news.ycombinator.com/item?id=49586898
3. getsentry/self-hosted (README): github.com/getsentry/self-hosted
4. GlitchTip: glitchtip.com
5. "DNS-O-Matic Is Shutting Down", r/homelab: reddit.com/r/homelab
6. Self-Hosted Sentry Alternative: TrapFall (our first post): blog.codecora.dev