Producer
The left panel: compose a message across five tabs, then Produce.
Everything you type (the value, the key, both halves of a header) is resolved against the global environment on the way out, so {{orderId}}and {{random.uuid}} become what they stand for. The topic is not resolved: it is chosen from the cluster's own list.
Value & format
The body, and how its bytes are read:
Key & partition
The key chooses the partition: the same key lands on the same partition, which is how a key's messages stay in order. An empty box means no key, which lets the client place it: by default it batches keyless messages onto one partition and shifts between them over time (sticky partitioning), rather than one message per partition in turn. That is not an empty key, which hashes like any other. The key is sent untrimmed, since trimming would change the partition it hashes to.
Partition is auto by default: let the key decide. Choose an explicit partition to override it; the choice offers only the partitions the selected topic actually has.
Headers
Key/value rows, and a name may repeat: Kafka keeps every one, unlike HTTP where clients tend to merge them. A row with a blank name is the editor's empty row and is dropped. A blank value box becomesno value at all, which is a different thing from a value of zero bytes.
Schema
Where the producer's Schema Registry connection lives, and what a produce will encode against once one is connected: the resolved subject, the registry's schema, and any field the value does not satisfy. The whole behaviour is described under Schema Registry, below.
Tombstones
A tombstone is a record with a key and no value at all. On a compacted topic it marks that key for deletion. It is not an empty message: Kafka keeps a zero-byte value and deletes the key for a missing one, so the two must stay apart.
A tombstone needs a key: it names what is gone. Producing one with no key is stopped, and the panel says why rather than writing a record that can do nothing.
Config
| acks | 0 no ack, 1 leader only, all every in-sync replica. Defaults to all: a green result should not mean a message that can still be lost. |
| compression | none, gzip, snappy, lz4 or zstd. Off by default: a local broker gains nothing from it. |
| timeout | How long delivery is retried before a send is given up, 1000–300000 ms (default 60000). This, not the retry count, is what actually ends a send. |
| idempotence | Exactly once, in order. Holds acks at all and manages retries itself, so the panel settles those for you rather than letting a send fail on a conflict. Turn it off and acks goes back to what you had chosen. |
| retries | How many times a failed send is retried, 0–100 (default 3). What actually ends a send is the timeout, not the count. |
The result
A send reports where it landed, shown where an HTTP request shows its status line:
With acks: 0 the bar reads Sent and not acknowledged instead of Delivered and an offset: the broker was never asked to answer.
86 B is the value as sent, before compression; the broker never reports what one message took once batched.
14:02:11 is the broker's own timestamp for the message, which is what a consumer will see.
A failure is described the same way the request line describes one, so it reads one way wherever it lands. A record the client refuses on this side, a partition the topic does not have or a message past the size limit, is reported as refused here, not as the cluster's answer: the broker never saw it.