/observability
v0.4 · Updated Sep 19, 2026
Observability is one of those big top-level skills that is actually composed of a lot of small things, but there are some key patterns. This is a parent skill that knows how to start the process and get an evaluation of what the observability is on a given platform or solution, or even a single-page app. It also knows about subskills that I can pull in. This is my starting point when I want to figure out: how observable is this app right now? If I'm looking across 15 to 20 apps, how observable are these relative to each other? Where's my vulnerability?
Kickoff prompt
Review this app for /observability. First, can I catch errors anywhere in the app? Second, while it is running, can I tell it is doing what I expected? Both parts together. Tell me what is missing.
Subskills
Start with where the app is hosted, or with Sentry if you need to see errors first.
- On the workbench
Cloudflare
The edge of the stack: tunnels, Pages, and Workers, and how a preview branch and a deploy Action ship the app.
- On the workbench
Fly.io
The app host when you do not want AWS. The setup that matters lives in a Dockerfile and fly.toml in the repo.
- On the workbench
Render
When the user wants the Render setup reviewed, including how it ships.
I wrote about this
Five things this rule looks for
- An error happens somewhere in the app, and you only hear about it when a person reports it.
- A failure in a background job, a webhook, or an AI step never shows up in the place you watch.
- The app is up, and you still cannot tell it is doing what you expected.
- A step finished without throwing, and you cannot tell it did the work.
- Later, you still cannot tell the running app kept doing what you set out to do.