A kitchen ticket has one job: tell a busy person what to make, in the order it should be made, without them stopping to decipher it. Most problems blamed on the printer are actually layout problems, placement problems, or a policy nobody wrote down.
The short answer: print one ticket per destination, put the item and quantity first, make modifiers impossible to miss, cut automatically, and decide in advance what happens when the paper runs out. Those five rules remove most of the friction that shows up at 20:30.
The ticket is read at arm's length
Eighty millimetres of thermal paper is about 42 characters per line. That budget goes fast, and a kitchen ticket is not read the way a receipt is read: it is scanned from a metre away, sideways, in a few seconds.
| Element | Where it belongs | Why |
|---|---|---|
| Order reference | Top, double height | Called out loud when the bag goes out |
| Service type (eat in, takeaway, delivery) | Top, immediately under | Changes packaging, so it must be seen first |
| Items and quantity | Body, quantity first | 2x before the name scans faster than after it |
| Modifiers and allergies | Indented under the item, never inline | Inline modifiers get read as separate items |
| Customer note | Bottom, separated | Rarely actionable mid-rush, but must exist |
| Time received | Bottom | Settles arguments about how long an order waited |
The single most common layout mistake is putting the shop name and address at the top in large type. That is receipt thinking. The kitchen already knows where it works, and the space costs a line that the order reference needs.
One ticket per destination
Cold station, hot station, bar and pass have different rhythms. Sending a single ticket to one printer means someone reads it, then walks it, or worse, retypes it.
Splitting by preparation area is the cheapest throughput improvement available, and with a print API it is a routing decision rather than a hardware one: the same order produces two payloads sent to two printer_uid values. Aggregators such as HubRise already carry the item categories you need to make that split, and if the routing rules live in an automation tool, Zapier can branch on them without code.
Print the full order on each ticket, with the items for other stations greyed out or omitted but the reference identical. A station that cannot see the whole order cannot tell when it is late.
What breaks at peak, in order of frequency
Paper. Always. A roll ends mid-service, and if nothing alerts, orders continue to arrive with no trace. Keep a spare roll on the printer itself, not in the office, and make sure someone is alerted when the printer stops responding.
Emoji and unusual characters. Item names come from a catalogue somebody edits from a phone. Thermal printers speak ESC/POS; an emoji in a product name can produce garbage or drop the connection. Transliterate before sending, which is a one-line fix and a category of incidents avoided.
Heat and grease. A printer above a fryer or a hot pass will fail early, and thermal paper darkens near heat. Mount it away from steam, at reading height, with the paper exit unobstructed.
Wi-Fi during service. A kitchen fills with people and metal, and the microwave sits on the same frequency. If tickets stop arriving at exactly 20:00 every Saturday, the network is the suspect, not the software. Ethernet is more reliable, and a printer with its own 4G connection removes the venue's network from the chain entirely, which matters most in places where you do not control the router.
Duplicate tickets. Usually a webhook retried after a slow response, occasionally a member of staff pressing print again because the first one did not appear. Both are addressed the same way: a stable key per order, so a repeat is detectable rather than reprinted.
The policy nobody writes down
Decide, before opening, what happens when a ticket does not print. There are only two acceptable answers: someone is alerted immediately, or the order is queued and delivered when the printer returns. Silence is the failure mode that costs a service, because the first sign is a customer asking where their food is.
For a kitchen, queueing alone is rarely enough. An order that prints twenty minutes late is worse than useless because service has moved on, so pair a short retry with a loud alert.
A ticket that works
*** ORDER A-1043 ***
DELIVERY - 19:42
2x MARGHERITA
- no basil
1x CARBONARA
- allergy: egg
--------------------------------
Note: ring the doorbell twice
Received 19:42
Bold and double height on the reference, a blank line before the note, an automatic cut at the end. All of it is markup inside the print payload; the receipt layout reference lists the tags, and logo printing covers the branding side for customer-facing copies.
Print this exact ticket on the free plan before service, and read it from where the cook stands rather than from the screen. Most layout problems are obvious from three feet away and invisible on a monitor.
Related: printing delivery platform orders covers aggregators, and reliable order printing covers the duplicate and retry logic in code.
FAQ
Should each kitchen station have its own printer?
If the stations have different rhythms, yes. Splitting by preparation area is the cheapest throughput gain available, and with a print API it is a routing decision rather than new hardware: one order produces one payload per station.
Why do kitchen tickets stop printing at exactly the same time every week?
Almost always the network rather than the software. A kitchen fills with people and metal at peak, and microwaves share the Wi-Fi frequency. Ethernet is steadier, and a printer with its own 4G connection removes the venue network from the chain.
How should modifiers and allergies appear on the ticket?
Indented on their own line under the item they belong to, never appended inline. Inline modifiers are read as separate items during a rush, which is how a no-basil pizza becomes two pizzas.
What should happen when the printer runs out of paper mid-service?
Someone has to be alerted immediately. Queueing alone is not enough for a kitchen, because an order printed twenty minutes late is worse than useless. Pair a short retry with a visible alert, and keep the spare roll on the printer.
Why does a product name with an emoji stop the printer?
Thermal printers speak ESC/POS, which has no representation for emoji or unusual symbols. Depending on the model the job prints as garbage or the connection drops. Transliterate item names before building the ticket.