Event schema

Everything a log drain sends is one batch. A batch carries a schema URL, a batch id, exactly one resource object describing the agent the records came from, and an array of records. The machine-readable definition is published as JSON Schema (draft 2020-12) at:

https://docs.heylua.ai/schemas/logs/1.0

That URL serves lua-log-batch.schema.json, which you can download or point a $ref at directly; the extensionless form above is the schema’s own $id. Validate against that file rather than against this page: it is the same file the platform’s own tests run their fixtures through. This page explains what each field means.

The envelope

{
  "schemaUrl": "https://docs.heylua.ai/schemas/logs/1.0",
  "batchId": "01JBW8N2Q4Z6H8Y0KX3R9T5V7M",
  "resource": { "…": "…" },
  "records": [ { "…": "…" } ]
}

Field	Type	Required	Notes
`schemaUrl`	string	Yes	Always `https://docs.heylua.ai/schemas/logs/1.0` for this major version. Also sent as the `X-Lua-Schema` header
`batchId`	string	Yes	A ULID. One HTTP request’s identifier, also sent as `X-Lua-Batch-Id`
`resource`	object	Yes	The agent, environment, and version these records came from
`records`	array	Yes	Up to 500 records (1,000 for Datadog)

A batch carries exactly one resource. Records from three agents in one flush become three batches, not one batch with a mixed resource. Group your ingest by resource['lua.agent.id'] and you never have to reconcile.

Consumers dedup on records[].id, never on X-Lua-Batch-Id. A retried record re-enters the queue and is re-sent with whatever else is then due, under a new batch id. The record id is the stable, at-least-once idempotency key; the batch id identifies one HTTP request, for support and tracing.

Resource

Resource attributes follow the OpenTelemetry semantic conventions where one exists, and are prefixed lua. where one does not.

Attribute	Type	Required	Value
`service.name`	string	Yes	The agent’s name, for example `support-agent`
`service.namespace`	string	Yes	The organization id
`service.instance.id`	string	Yes	The agent id
`service.version`	string	No	The agent version that served
`deployment.environment.name`	string	Yes	`production` or `sandbox`
`gen_ai.agent.id`	string	Yes	The agent id, under the GenAI convention
`gen_ai.agent.name`	string	No	The agent’s name, under the GenAI convention
`cloud.region`	string	No	The region the delivery left from, for example `eu-west-1`
`lua.org.id`	string	Yes	The organization id. The tenancy key — assert it on every record you ingest
`lua.agent.id`	string	Yes	The agent id

Record

Field	Type	Required	Value
`id`	string	Yes	The log entry’s id. The deduplication key
`timestamp`	string	Yes	RFC 3339. When the thing happened
`observedTimestamp`	string	Yes	RFC 3339. When the platform picked the entry up for delivery
`eventName`	string	Yes	`lua.<source>.<suffix>`; see below
`severityNumber`	integer	Yes	`5`, `9`, `13`, or `17`
`severityText`	string	Yes	`DEBUG`, `INFO`, `WARN`, or `ERROR`
`body`	string	No	The log message, scrubbed. Absent on content records when content is off
`traceId`	string	No	32 lowercase hex characters, when the turn carried W3C trace context
`spanId`	string	No	16 lowercase hex characters
`attributes`	object	Yes	String, number, and boolean values only. Never nested

attributes is flat by design: every value is a string, a number, or a boolean. Destinations that index attributes (Datadog facets, Loki structured metadata, Elastic fields) can take the whole object without a flattening step.

Severity

The mapping is fixed. severityNumber follows the OpenTelemetry log data model, so a destination that understands OTel severity ranges sorts Lua’s records correctly without configuration.

What it is	`severityNumber`	`severityText`
A `debug` line	`5`	`DEBUG`
An `info` line	`9`	`INFO`
An execution `start`	`9`	`INFO`
An execution `complete`	`9`	`INFO`
A `warn` line	`13`	`WARN`
An `error` line	`17`	`ERROR`
An execution `error`	`17`	`ERROR`

A drain’s --min-severity compares severityNumber against debug: 5, info: 9, warn: 13, error: 17 and keeps what is greater than or equal.

eventName

eventName = "lua." + <source> + "." + <suffix>

Every value matches ^lua\.[a-z_-]+\.[a-z]+$. The name never contains an id: a failing Shopify MCP tool is lua.mcp.error, not lua.mcp_shopify.error. Filter on the name and group by an attribute. For the eighteen agent sources the suffix is the line’s level:

lua.skill.debug          lua.skill.info          lua.skill.warn          lua.skill.error
lua.job.*                lua.webhook.*           lua.trigger.*           lua.preprocessor.*
lua.postprocessor.*      lua.device.*            lua.device-trigger.*    lua.mcp.*
lua.rag.*                lua.runtime.*           lua.model-resolver.*    lua.workflow.*
lua.workflow-step.*      lua.workflow-script.*   lua.user_message.*      lua.agent_response.*
lua.agent_error.*

lua.device.* is the one name in that list nothing emits yet: device work is logged under device-trigger, so a drain that selects device receives no lua.device.* records. The name is reserved and will start appearing within this major version, which is why a consumer switches on eventName with a default branch. For execution records the suffix is the phase or the outcome:

lua.execution.start      lua.execution.complete      lua.execution.error
lua.execution.completed  lua.execution.failed        lua.execution.timeout   lua.execution.killed

The four lua.execution.* outcome names on the second line, and the adjacent-record names below, are available from lua-cli 3.39.0.execution has always been a default source, so a drain that selects it receives those four names with no opt-in. They are new values on an existing source, which is additive under the policy below — and the clearest possible reason for the default branch that policy asks for. lua.execution.status carries the exact outcome, and lua.log.type is metric on all seven.

Adjacent-record event names

Six sources carry the platform’s own records of what happened next to a turn rather than lines an agent printed. Their names follow the same lua.<source>.<suffix> rule:

Source	`eventName`	Suffixes
`delivery`	`lua.delivery.<status>`	`queued`, `accepted`, `sent`, `delivered`, `read`, `failed`, `expired`
`trigger-execution`	`lua.trigger-execution.<status>`	`accepted`, `completed`, `failed`, `skipped`, `rejected`, `started`
`job-execution`	`lua.job-execution.<status>`	`completed`, `failed`, `timeout`, `killed`, `cancelled`, `abandoned`, `reaped`
`workflow-run`	`lua.workflow-run.<segment>`	`run`, `step`, `subrun`, `approval`, `signal`, `timer`, `billing`, `journal`, `goal`, `schedule`, `sweeper`, `workflow`, `connection`
`voice-call`	`lua.voice-call.<status>`	`active`, `ringing`, `answered`, `completed`, `failed`, `rejected`, `busy`, `timeout`, `cancelled`, `transferred`
`workflow-audit`	`lua.workflow-audit.info`	one name for the whole audit trail

Severities: lua.delivery.failed is 17, lua.delivery.expired is 13, every other lua.delivery.* is 9. Every lua.workflow-audit.info is 9 — so a drain at --min-severity warn receives none of them. workflow-run severity follows the event type: *.failed, *.timed_out, run.failing and journal.divergence are 17; cancellations, expiries, throttles, rejections and run.gated are 13; run.log, step.progress and run.phase are 5; everything else is 9.

The suffix is a summary. Switch on the attribute

This is the consumer contract for every one of these sources, and it is worth writing into your ingest before the first record arrives. An eventName suffix admits lowercase letters only — no digits, no _, no . — and several of these vocabularies do not fit that. So the suffix is a normalised summary and the exact value always rides an attribute. Nothing is lost, but the name is not the value:

Source	What the suffix does to the exact value	Switch on this instead
`trigger-execution`	Collapses the qualified statuses: a skip for any reason becomes `skipped`, an unverified rejection becomes `rejected`, a workflow start becomes `started`	`lua.trigger.status`
`job-execution`	Nothing — the seven terminal statuses are already legal. In-flight states produce no record at all	`lua.job.status`
`execution`	Nothing on the four outcomes	`lua.execution.status`
`workflow-run`	Keeps only the event type’s leading segment: `run.completed` → `run`, `step.retry_scheduled` → `step`	`lua.workflow.event_type`
`voice-call`	Nothing — every status is already legal	`lua.voice.status`
`workflow-audit`	Always `info`, whatever the action was	`lua.audit.action`

Two of those deserve the emphasis:

lua.workflow-run.* is the run/step distinction, not the outcome. The leading segment is used because it is a small closed set that survives the event vocabulary growing, and because it preserves the distinction a consumer routes on. The trailing segment would have collapsed run.completed and step.completed into one name and produced unreadable suffixes like retryscheduled. lua.workflow.event_type carries the full dotted type.
lua.workflow-audit.info is one name for roughly sixty actions. An audit action is dotted and underscored (workflow.run.step_parked) and could never be a legal suffix; widening the name pattern would be a breaking change rather than an additive one. Switch on lua.audit.action, with a default branch. See Workflow audit records.

And four names are synthetic — generated by the drain itself rather than by your agent. Every one of them carries lua.log.type, lua.source, and lua.drain.id, and then what the table names:

`eventName`	When	`lua.source`	Also carries
`lua.drain.test`	`lua drains test`, the dashboard test button, and every ownership verification	`drain`	—
`lua.drain.heartbeat`	Every five minutes, to a `healthy` drain only	`drain`	`lua.drain.backlog`
`lua.drain.dropped`	On the first success after records were dropped	`drain`	`lua.drain.dropped_count`, `lua.drain.dropped_from`, `lua.drain.dropped_to`
`lua.truncated.warn`	The runtime dropped lines from one execution because it printed too many	`truncated`	`lua.execution.id`, `lua.truncated.lines`

lua.source follows the name: the source segment of lua.drain.test is drain, and of lua.truncated.warn it is truncated. So a query for everything the drain said about itself is lua.source = "drain", and it never catches a record one of your agents wrote. Each synthetic record also carries an attribute no agent record has — lua.drain.id on the three lua.drain.* records, lua.truncated.lines on the truncation one — which makes them cheap to select without a wildcard match on the name. The monitor packs rely on that. Synthetic records do not count against the drain’s daily quota, and they do count in health.deliveredCount24h.

Attributes

Attributes are present when the platform has the value and absent otherwise. A missing attribute is never an error and never an empty string.

Attribute	Type	On	Value
`lua.log.type`	string	All	`log` for a printed line, `metric` for an execution record
`lua.source`	string	All	The selector source, for example `skill` or `execution`; `drain` on the three `lua.drain.*` records and `truncated` on `lua.truncated.warn`
`lua.duration_ms`	number	Where timed	Milliseconds
`lua.execution.id`	string	Sandboxed code	The execution this line belongs to
`lua.execution.seq`	number	Sandboxed code	Index of the line within its execution. Sort on it to replay an execution in order
`lua.primitive.id`	string	Named primitives	The skill, job, webhook, processor, or device id
`lua.primitive.name`	string	Named primitives	Its name, as `lua logs --name` takes it
`lua.tool.id`	string	Tool calls
`gen_ai.tool.name`	string	Tool calls	The tool name the model called
`gen_ai.operation.name`	string	Where derivable	`execute_tool` for `skill` and `mcp`; `chat` for `user_message` and `agent_response`; `invoke_agent` for `job`, `webhook`, `trigger`, and `device-trigger`
`gen_ai.conversation.id`	string	Conversation turns	The run id
`lua.run.id`	string	Conversation turns	The same value, under the Lua prefix
`gen_ai.request.model`	string	`agent_response`, `agent_error`	The `provider/model` code that served the turn
`lua.channel`	string	Where known	`pop`, `whatsapp`, `slack`, `email`, `api`, `dev`, …
`user.id`	string	End-user traffic	The end user. Dropped entirely when the drain’s `redact` list names it
`lua.agent.version`	string	Where known	Also on the resource
`lua.content.withheld`	boolean	Records with a content half	`true` when the record arrived but the content part of it — a `body`, or one or more attributes — was withheld because the drain does not include content. Advisory, never authoritative
`exception.type`	string	Errors	Parsed from the thrown error
`exception.message`	string	Errors
`exception.stacktrace`	string	Errors	Capped at 8 KB
`app.<key>`	string, number, boolean	Lines your code described with `log.*`	A field you supplied, under the key you gave it. A list field arrives joined with `,` and carries the companion below
`app.<key>.count`	number	Beside `app.<key>` when that field was a list	How many elements were joined into `app.<key>`. It cannot collide with a field of your own: a key you write may not contain a `.`
`app.lua_fields_clamped`	boolean	When that call’s fields were cut to fit a byte ceiling	`true` — one value was over the per-value ceiling, or the fields together were over the per-call one. A reserved key: a call that sets it itself is refused
`lua.log.structured`	boolean	Lines whose `log.*` call carried at least one field	`true`. Selects the lines your code described, as against the lines it merely printed. A `log.*` call with no fields does not carry it
`lua.app_fields.dropped`	number	Rarely	How many `app.*` attributes were shed to bring the record under its destination’s per-record size cap, largest value first. Platform attributes are never shed

Everything under app. comes from a log.* call in your own code, and the platform adds exactly one key of its own there — app.lua_fields_clamped, which is reserved, so nothing you can name collides with it. The two lua.* keys are the platform describing what it did with your fields. Emit your own fields covers the limits on them, what each destination does with them, and how a drain’s redact list and the scrubber reach them. traceId and spanId come from W3C trace context when the turn carried it. A malformed value yields neither field; it is not an error and the record is still delivered.

Adjacent-record attributes

Every key below is new with the adjacent-record sources, and every one is optional in the same way as the table above: present when the platform has the value, absent otherwise, never an empty string. Keys marked content arrive only on a drain with --include-content. lua.channel, lua.provider, user.id, lua.run.id, lua.duration_ms and lua.log.type are unchanged in meaning — these records simply also carry them.

`lua.delivery.*`

Attribute	On	Meaning
`lua.delivery.id`	`lua.delivery.*`	The delivery’s own id
`lua.delivery.status`	`lua.delivery.*`	The event name’s own suffix, for destinations that facet on attributes
`lua.delivery.error`	`lua.delivery.failed`	`category/code: title`, at most 512 characters. Never the vendor’s free-text detail
`lua.delivery.provider_message_id`	`lua.delivery.*`	The vendor’s own message id
`lua.delivery.recipient`	`lua.delivery.*`	The vendor address, masked to its last four characters behind `…`. The full address is content

A lua.delivery.* record carries no body at all. Delivery records has the statuses, the masking rule and the two statuses nothing reports yet.

`lua.trigger-execution.*`

Attribute	Meaning
`lua.trigger.id`	The trigger the dispatch was for. Never the token
`lua.trigger.status`	The exact status the suffix was derived from
`lua.execution.id`	The dispatch’s own id
`gen_ai.tool.name`	Direct tool-binding dispatches only
`lua.tools.used`	Comma-joined tool names, on a completed turn
`lua.event.id`	The retry-stable vendor event id, on connection-event sources
`lua.run.id`	The workflow run a dispatch started, when it started one
`lua.duration_ms`	Present once the dispatch has completed
`exception.type`, `exception.message`, `exception.stacktrace`	From the dispatch’s error
`lua.trigger.payload`	content — the request body as stored
`lua.trigger.response`	content — the agent’s answer, or the tool result

One dispatch produces up to two records: the accept and the outcome.

`lua.job-execution.` and `lua.execution.`

Attribute	On	Meaning
`lua.job.id`	`lua.job-execution.*`	The job
`lua.job.version_id`	`lua.job-execution.*`	The job version that ran
`lua.job.status`	`lua.job-execution.*`	The exact terminal status
`lua.job.retry_count`	both	Completed prior attempts of this occurrence
`lua.execution.id`	both	The occurrence
`lua.execution.attempt`	both	1-based attempt number
`lua.execution.status`	`lua.execution.*`	The exact terminal status
`lua.execution.site`	`lua.execution.*`	`webhook` or `device-trigger`
`lua.event.id`	`lua.execution.*`	The retry-stable event id the occurrence was for
`lua.wall_ms`	both	Wall-clock run time
`lua.cpu_ms`	both	User plus system CPU time
`lua.cpu_user_ms`, `lua.cpu_sys_ms`	both	The two halves of it
`lua.max_rss_mb`	both	Peak resident set
`lua.duration_ms`	both	Milliseconds
`exception.*`	both	From the failure

Neither source has a content half, ever. A job result is arbitrary code output and is deliberately not offered, so --include-content changes nothing about these records and they never carry lua.content.withheld. job-execution emits on terminal transitions only. A job that is claimed, running, or has been asked to cancel is not an outcome and produces nothing.

`lua.workflow-run.*`

Attribute	Meaning
`lua.workflow.run_id`	The workflow run
`lua.workflow.seq`	The run’s own monotonic event number. Order by this
`lua.workflow.event_type`	The full dotted event type the suffix was derived from
`lua.workflow.step_id`	The step, when the event is step-scoped
`lua.workflow.attempt`	The step attempt
`lua.workflow.actor`, `lua.workflow.actor_id`	Who caused the event
`user.id`	The end user, when there is one
`lua.workflow.data`	content — the event’s own `data` block

Order a workflow run by lua.workflow.seq, never by timestamp. seq is the run’s own monotonic allocation: it is gapless within a run, it survives a retried write, and it is the only field that puts two events written in the same millisecond in the right order. Sort ascending on (lua.workflow.run_id, lua.workflow.seq) and you can replay a run exactly.

traceId and spanId on these records come from the run event’s own trace context, so traceId equals the run’s trace. workflow-run is by far the highest-volume of these sources, and there is no curated subset of event types — a gapped stream would make seq useless. The volume knob is --min-severity: at the default info a drain already drops run.log, step.progress and run.phase. lua.workflow.actor is present whenever the run event recorded one, and absent otherwise — a missing attribute, never a wrong one. Do not treat its absence as “the system did it”.

`lua.voice-call.*`

Attribute	Meaning
`lua.voice.call_id`	The call
`lua.voice.status`	The exact status
`lua.voice.direction`	`inbound` or `outbound`
`lua.voice.provider`	`livekit`, `vonage`, or `recall`
`lua.voice.channel`	`phone`, `web`, `whatsapp`, or `meeting`
`lua.voice.end_reason`	How the call ended
`lua.voice.duration_s`	Call length in seconds. `lua.duration_ms` carries it in milliseconds too
`user.id`	The end user, when there is one — sometimes masked, see below
`exception.type`	`voice_call_<status>`, on a status whose severity is `13` or `17`
`exception.message`	The provider’s end reason — the same value as `lua.voice.end_reason`, in the shape an OpenTelemetry consumer already reads
`lua.voice.recording_url`	content — a fetchable handle on the call’s audio

A voice record never carries the caller’s or the callee’s phone number under any key, with or without --include-content, and the transcript is never a candidate either. A source that carried them would be unusable without a redact list, which is not a property to design in.

All ten statuses now have a producer

Records on this source are built from two different places in the platform, and nothing on a record says which. That is deliberate: the source, the attribute names, the severity per status, and the record id are identical either way. What changed is coverage. Until this release only completed and transferred were ever sent, and only on a call that produced a transcript. Eight statuses that had no producer now have one — active, ringing, answered, failed, rejected, busy, timeout, and cancelled — from the telephony call lifecycle.

If your ingest assumes “a voice-call record means the call ended”, it now also means the call rang. Branch on lua.voice.status, with a default — which is what the suffix rule has always said for this source.exception.type and exception.message appear on lua.voice-call.* for the first time as well, on the 13 and 17 statuses. A record on the happy path carries neither.

Two things not to read too much into

user.id on this source may be masked. Where the producer’s user id is the caller’s phone number, it is emitted as … plus the last four characters — the same mask and the same rule as lua.delivery.recipient — and the full value is content, reaching only a drain with --include-content. Where it is an ordinary Lua user id, it arrives as stored. Treat user.id on lua.voice-call.* as possibly-masked and never parse it as an identifier. A value of four characters or fewer masks to the bare ….
lua.voice.recording_url is not a reliable “this call was recorded” signal. One producer sets it routinely; the other almost never can, because the provider’s recording callback lands after the terminal call event, so by the time that record is built there is no URL to carry. Its absence on a lua.voice-call.completed does not mean the call was not recorded.

Both producers can build a completed record for the same call, with the same id — and which of the two you receive is a race. Everything either one carries is documented above; neither invents a field the other contradicts. If your consumer needs a field only one of them sets, select a status it is guaranteed on rather than completed.

`lua.workflow-audit.info`

Attribute	Meaning
`lua.audit.action`	The audit action, verbatim. Switch on this, not on the event name
`lua.audit.schema`	The audit entry’s own schema id
`lua.audit.actor.type`, `lua.audit.actor.id`	Who acted
`lua.audit.target.type`, `lua.audit.target.id`	What was acted on
`lua.run.id`, `lua.step.id`	The run and step, on run- and step-scoped actions
`lua.audit.evidence.surface`	`desktop`, `api`, `cli`, …
`lua.audit.evidence.api_key.id`	The API key that acted
`lua.audit.actor.label`	content — the actor’s display label, often an email address
`lua.audit.evidence.session.id`	content — the session that acted
`lua.audit.evidence.ip`	content — the request’s source address
`lua.audit.evidence.user_agent`	content — the request’s user agent
`lua.audit.metadata`	content — the entry’s metadata as one JSON string, at most 4 KB

lua.audit.metadata is a JSON string, not a nested object: attribute values in this schema are scalars and that does not change. Audit metadata is free-form per action, so flattening it would put unbounded per-action key names into every destination’s attribute index. Over the 4 KB cap the whole value is replaced by {"__truncated":true,"bytes":<n>} — so an oversized entry is never dropped, never silently halved, and still parses. A lua.workflow-audit.info record carries no body. Workflow audit records has the selectors that will silently deliver you nothing, and the SIEM webhook migration.

Content and withheld values

Two things decide what arrives: the drain’s --include-content flag, and whether the record had a content half in the first place. Without --include-content:

a user_message or agent_response record is still delivered — so you can see that a turn happened, on what channel, for which user — but body is absent;
every attribute marked content above is absent. Not empty, not masked: absent. The rest of the record arrives intact, so the dispatch, the run, the call, the delivery and the audit action all stay visible;
the record carries lua.content.withheld: true.

With it, those values appear, having passed the same scrubber as everything else, and each one is capped at 8 KB — a value that was cut ends with a literal marker:

… [truncated]

lua.audit.metadata is the one exception to the 8 KB cap: it is capped at 4 KB and replaced wholesale by a truncation marker rather than cut, so that it still parses as JSON.

lua.content.withheld is advisory. The presence of each key is authoritative.The flag marks that a record had a content half and did not receive it. It is deliberately not per-key, so do not infer from it which keys you are missing — read the keys.It follows that some records never carry it at all, and that is correct rather than a bug: lua.job-execution.* and lua.execution.* have no content half to withhold, and a lua.delivery.* record with no recipient has nothing to unmask. Going the other way, lua.workflow-audit.info always carries it when content is off, even for an entry that recorded no evidence — so that a quiet entry can never be mistaken for a redacted one.On lua.voice-call.* the flag is doubly advisory: a masked user.id is present but shortened rather than absent, so the key being there says nothing about whether you are seeing the whole value.

A drain that selects only adjacent-record sources is not a content drain: --include-content’s acknowledgement, and the refusal to turn content off while naming a content source, both concern user_message and agent_response alone.

OTLP mapping

An OTLP drain sends the same information as an OTLP/HTTP ExportLogsServiceRequest in JSON encoding. The mapping is one-to-one.

Batch field	OTLP field
`resource`	`resourceLogs[0].resource.attributes[]`, as `{ key, value: { stringValue } }`
`schemaUrl`	`resourceLogs[0].schemaUrl`
—	`resourceLogs[0].scopeLogs[0].scope` = `{ "name": "lua.log-drain", "version": "1.0" }`
`records[].timestamp`	`logRecords[].timeUnixNano` (a string of nanoseconds)
`records[].observedTimestamp`	`logRecords[].observedTimeUnixNano`
`records[].eventName`	`logRecords[].eventName`
`records[].severityNumber`	`logRecords[].severityNumber`
`records[].severityText`	`logRecords[].severityText`
`records[].body`	`logRecords[].body.stringValue`
`records[].traceId`	`logRecords[].traceId` (lowercase hex)
`records[].spanId`	`logRecords[].spanId` (lowercase hex)
`records[].id`	`logRecords[].attributes[]`, key `log.record.uid`
`records[].attributes.*`	`logRecords[].attributes[]`, typed `stringValue`, `intValue`, `doubleValue`, or `boolValue` by the JavaScript type; whole numbers become `intValue` (a string, per the OTLP JSON encoding) and the rest `doubleValue`

Versioning

The schema URL carries the major version, and the schemaUrl field in every batch tells you which one you received. Within 1.0, changes are additive only. That means:

New optional attributes keys may appear at any time, on any record.
New eventName values may appear — new sources, new synthetic records. A consumer that switches on eventName must have a default branch.
New optional fields may be added to resource and to records[].
New severityNumber values within the OpenTelemetry ranges may appear; compare with >= against the boundaries above rather than with == against the four current values.

These are breaking and bump the URL instead: renaming a field or an attribute, changing a field’s type, removing a required field, making an optional field required, or changing the meaning of an existing eventName. A new major version is published at a new URL — …/schemas/logs/2.0 — and existing drains keep receiving 1.0 until they are moved. Build your ingest so an unknown attributes key is carried through rather than rejected, and a schema addition never pages you.

Changelog

Version	Date	Change
`1.0`	Unreleased	An export is masked by your organization’s own scrub rules too. No schema change — no new field, no new `eventName`, no new attribute key — and an export part validates against `logs/1.0` exactly as it did before. What moves is the content of some string values: an export applied Lua’s built-in scrub classes alone, while a drain delivery applied those and the rules you added yourself, so a value your drain masked arrived in the clear in your export. It now carries the same `[redacted:org:<your rule id>]` mask in both places. Ingest that parsed such a value as data — an account number, an identifier — will see the mask in export files where it previously saw the raw value. Nothing is ever unmasked by this, the mask shape is unchanged, and an organization with no drain rules sees no change at all. It may not be enabled on your deployment yet.
`1.0`	Unreleased	The SIEM overlap headers are withdrawn. No schema change — not one byte of a batch body moves — and it is listed here because the part that changed is the one part of a delivery a validating consumer never sees. `X-Lua-Signature-Legacy` and `X-Lua-Timestamp`, which a drain created by the workflow SIEM webhook migration carried for one release, are no longer sent on any drain. Verify `X-Lua-Signature`, and note that its `t=` is whole seconds where the retired header was milliseconds.
`1.0`	23 September 2026	`voice-call` gains its second producer. No new `eventName` and no new attribute key. Eight `lua.voice-call.` statuses that had no producer now have one — `active`, `ringing`, `answered`, `failed`, `rejected`, `busy`, `timeout`, `cancelled`; `exception.type` and `exception.message` appear on this source for the first time; and `user.id` on a `lua.voice-call.` record is masked when it is a caller’s number, with the full value behind `--include-content`. Details.
`1.0`	23 September 2026	The adjacent-record sources. Six new values for `lua.source` — `delivery`, `trigger-execution`, `job-execution`, `workflow-run`, `voice-call`, `workflow-audit` — with their `eventName` values and around fifty new optional `attributes` keys; four new `lua.execution.*` outcome names on the existing `execution` source.
`1.0`	Unreleased	First published version.

The schema file itself did not change. eventName is a pattern and attributes is open, so a consumer that validates a batch against the published logs/1.0 keeps validating one without touching anything. Every addition in the row above is a new value or a new optional key, which is what the policy above permits at any time. What a consumer does need is the default branch on eventName — this release is the first time that branch is actually reached. The date above is the release in force as this is written and is subject to change until the release is announced.

Next steps

Delivery guarantees

At-least-once, batching, retry, and drop semantics.

Verify signatures

The X-Lua-Signature format and working verifiers.

Generic HTTPS

A receiver that validates this schema end to end.

Grafana dashboard

Panels built on these field names.

Get started

Concepts

Build

Channels

Integrations

Devices

Ship and operate

Ship logs to your stack

Marketplace

Build with AI

Examples

The envelope

Resource

Record

Severity

eventName

Adjacent-record event names

The suffix is a summary. Switch on the attribute

Attributes

Adjacent-record attributes

`lua.delivery.*`

`lua.trigger-execution.*`

`lua.job-execution.` and `lua.execution.`

`lua.workflow-run.*`

`lua.voice-call.*`

All ten statuses now have a producer

Two things not to read too much into

`lua.workflow-audit.info`

Content and withheld values

OTLP mapping

Versioning

Changelog

Next steps

Delivery guarantees

Verify signatures

Generic HTTPS

Grafana dashboard

​The envelope

​Resource

​Record

​Severity

​eventName

​Adjacent-record event names

​The suffix is a summary. Switch on the attribute

​Attributes

​Adjacent-record attributes

​lua.delivery.*

​lua.trigger-execution.*

​lua.job-execution.* and lua.execution.*

​lua.workflow-run.*

​lua.voice-call.*

All ten statuses now have a producer

Two things not to read too much into

​lua.workflow-audit.info

​Content and withheld values

​OTLP mapping

​Versioning

​Changelog

​Next steps

Delivery guarantees

Verify signatures

Generic HTTPS

Grafana dashboard

The envelope

Resource

Record

Severity

eventName

Adjacent-record event names

The suffix is a summary. Switch on the attribute

Attributes

Adjacent-record attributes

`lua.delivery.*`

`lua.trigger-execution.*`

`lua.job-execution.` and `lua.execution.`

`lua.workflow-run.*`

`lua.voice-call.*`

`lua.workflow-audit.info`

Content and withheld values

OTLP mapping

Versioning

Changelog

Next steps