ConstReadonlyAI_ERROR: "ai.error"ReadonlyAI_REQUEST: "ai.request"An inference call was made to Workers AI or an AI gateway.
ReadonlyANALYTICS_ERROR: "analytics.error"A metric could not be written to Analytics Engine.
ReadonlyAUTHENTICATION_FAILED: "authentication.failed"A caller presented no credential, or the wrong one.
ReadonlyAUTHENTICATION_SUCCEEDED: "authentication.succeeded"A caller presented a credential this Worker accepted.
ReadonlyAUTHORIZATION_DENIED: "authorization.denied"A caller authenticated but may not do what they asked.
ReadonlyDATABASE_ERROR: "database.error"A D1 or Hyperdrive query failed.
ReadonlyEXTERNAL_API_ERROR: "external_api.error"A call to a service this Worker does not own failed, or answered with an error status.
ReadonlyEXTERNAL_API_REQUEST: "external_api.request"A call left this Worker for a service it does not own.
ReadonlyKV_ERROR: "kv.error"A KV read or write failed.
ReadonlyQUEUE_ERROR: "queue.error"A queue send or a batch handler failed.
ReadonlyR2_ERROR: "r2.error"An R2 operation failed.
ReadonlyRATE_LIMIT_EXCEEDED: "rate_limit.exceeded"A rate limiter refused a request.
ReadonlyRATE_LIMIT_UNAVAILABLE: "rate_limit.unavailable"A rate limiter could not be consulted, and the request was let through.
ReadonlyREQUEST_COMPLETED: "request.completed"A request finished and produced a response — any status below 500.
Emitted once per request by
logToAnalytics, at info for a success and
warn for a 4xx. The level carries the outcome so the event does not
have to: one name means "a request ended", and status in the payload says
how.
ReadonlyREQUEST_FAILED: "request.failed"A request ended in a fault — a 5xx, or an exception nothing caught.
The counterpart to events.REQUEST_COMPLETED, and the one line a production investigation starts from. Split out rather than folded into the status field because "how often is this Worker failing" should be a filter on one value, not a range query.
ReadonlyREQUEST_UNHANDLED: "request.unhandled"An exception reached the application's error boundary.
Distinct from events.REQUEST_FAILED, and the pair is deliberate.
Inside a Hono app the request middleware never sees the exception — the
framework has already turned it into a 500 by the time next() returns —
so the only place the stack exists is app.onError. One name would make
every unhandled failure count twice; two names keep request.failed an
honest count of failed requests and give the stack a filter of its own.
Both lines carry the same request id, so one query on that id returns the failure and its cause together.
ReadonlySCHEDULED_COMPLETED: "scheduled.completed"A cron trigger finished its work.
ReadonlySCHEDULED_FAILED: "scheduled.failed"A cron trigger failed.
ReadonlySCHEDULED_STARTED: "scheduled.started"A cron trigger began.
An event name is the field a log query filters on, so the value of one is
entirely in its being spelled the same way twice. request.failed and
request-failed are two events to a collector and one to a reader, and the
second only ever shows up as a gap in a chart nobody thinks to question.
These constants exist to make the spelling unavailable to typos.
subject.outcome, lowercase, dotted, snake_case within a segment:
external_api.error, invoice.fetch.completed. The subject is what the
event is about and the outcome is what became of it.
The subject is never the Worker. Workers Logs already records which
script wrote a line and offers it as a column, so example-worker in front
of order.sent buys nothing and costs the query event = order.sent its
meaning across services. service says where
it happened; event says what happened; the two are read together.
Only the cross-cutting names — the ones that mean the same thing in every
Worker, so that "error rate by event" is answerable across deployments. A
Worker's own vocabulary is its own: order.sent, message.received, and
invoice.fetch.completed are meaningful exactly once each and belong beside
the code that emits them, as string literals. Hoisting them here would centralise a list nothing shares.
An inference call failed.