Errors you can see from outside

A console.log is a diagnostic for someone sitting in front of the machine. Once the tool is deployed, nobody is.

Two audiences, two channels

The user needs to know what to do. Course 4 settled this: four error kinds, four messages, and 429 never rendered as "something went wrong".

You need to know it happened at all. That is a different channel, and it must reach you without anyone reporting it. A tool whose failures are only visible to the person suffering them is a tool that stays broken.

Log on the server, structured, without secrets

console.error(JSON.stringify({
  event: "proxy_upstream_error",
  status: res.status,
  path: upstream.pathname,     // never the full URL — the key is in it
  ts: Date.now(),
}));

Three rules and each has a specific reason. Structured, not prose, because you will want to search it. Never the full upstream URL, because the key is a query parameter on it and logs are the second most common way keys leak after bundles. The path, not the body, because the body is data you may not redistribute.

What is worth an alert to you

Not everything. Four things:

• A 429, because it means the wall arrived and you want to know when.
• A spike in 5xx, because upstream is broken and your tool looks broken.
• The store failing, because saves are silently not happening.
• The app failing to boot, which the deploy should have caught and sometimes does not.

Everything else goes in the log and waits until you look.

A health endpoint you can actually use

GET /api/health -> { ok: true, store: "up", upstream: "up", calls_used: 340 }

Two properties matter. It must not need the API key to answer — if checking health spends quota, you will stop checking. And it must report the store separately from upstream, because those fail for different reasons and need different responses from you.

This is what unit 3's monitoring watches, and it is ten lines.

Errors in the browser too

Course 4 put an error boundary around each panel. Wire those boundaries to report — a small endpoint that takes a message and a stack is enough. Without it, a render bug in one panel is invisible to you forever, because the person who hits it just closes the tab.

Try it now

Break each of the four alertable things on purpose — exhaust your quota, stop the store, throw at boot — and confirm you find out without looking at the screen. The one that does not reach you is the one that will happen while you are away.