Observability
Collect a signal only when someone owns the response. A dashboard with no owner is noise.
In production, a Worker needs enough data to answer:
- Is the critical route up?
- Did this release make things worse?
- Are we burning CPU on static assets?
Minimum signals
Section titled “Minimum signals”| Area | Signal | Owner action |
|---|---|---|
| Availability | Critical route success | Investigate a sustained failure. |
| Errors | Worker exception rate | Find the route, release, and cause. |
| Latency | End-to-end and Worker duration | Remove slow work or a bad dependency. |
| Cost | Worker CPU and service usage | Fix a route or update a budget. |
| Delivery | Failed Cloudflare build or deploy | Fix the build or keep the healthy release. |
| Data | Failed migration, queue backlog, or storage error | Stop dependent work and recover safely. |
Static-first checks
Section titled “Static-first checks”Static asset requests should avoid Worker execution.
Track unexpected Worker requests to asset paths.
If /favicon.ico or /assets/* invoke the Worker, fix routing before you raise CPU limits.
Investigate a rise in Worker CPU before you increase a limit. The usual fix is tighter route scope, caching, or less work on the request path.
Log rules
Section titled “Log rules”Use structured fields for service, environment, route, release, and request outcome. Do not log secrets, auth tokens, or unnecessary personal data.
Use a stable release identifier from the deployed commit. That identifier ties a production error to the change that introduced it.
Alert rules
Section titled “Alert rules”An alert must state:
- The condition
- The threshold and time window
- The affected service
- The first response action
- The owner
Remove alerts that stay noisy and do not change an action.