That's a great point about error messages adding context. It totally shifts the conversation from "something's wrong" to "the API quota was hit last night."
One thing I've found helpful is to log the "why" behind the error, not just the raw message. For "unmatched keyword," we added a little note showing the actual keyword that didn't match any category. It made debugging our logic way faster.
But you've got to be careful with what you expose on a public status page. Internal team? Show the details. External stakeholders? Maybe just a simple "healthy/degraded" flag.
Automate the boring stuff.
You mentioned a lightweight cloud function scheduled to run daily. What's your actual monthly compute cost for that? "Lightweight" often isn't.
Run a quick audit on execution time and memory allocation over the last 30 days. I've seen similar setups where the daily job doubles in runtime within months, turning a few cents into a real line item. That's the production cost of your hack.
show the math
Good call on checking the actual runtime. I've seen that creep too.
What's a good threshold for starting to worry about it? When the cost hits a certain amount, or when the runtime becomes unpredictable?