Skip to content

Labels that print, and prove they printed

Of the twenty-one Whatnot extensions we surveyed, four print labels at all, and none of them check whether the label actually came out. That is the whole problem with print automation: a job that silently fails looks exactly like a job that worked, and you find out at the post office three days later. Everything in this section exists to close that gap.

Capabilities
10
This group
How you know it printed

A late confirmation un-fails the job

This is the detail that shows the rest is real. If a printer is slow and the confirmation arrives after the deadline has already marked the job failed, the record is corrected back to completed rather than leaving a failure on file for a label that physically exists. A tool that only records optimistic outcomes cannot do this, because it never had a deadline to be late for.

Every job is a tracked state machine

A print is not a fire-and-forget message. It moves from queued to assigned to printing and then to completed or failed, with a separate timestamp written at each step. That is what makes every other claim on this page answerable rather than assumed.

A ten-second deadline on the whole round trip

A job handed to a machine that has not reported back within ten seconds is failed automatically, by a watchdog that checks every two seconds. A live seller needs to know inside the same beat whether a label landed, so the deadline is deliberately tight.

Plain English for why a label has not printed

A waiting label comes with a reason, not a spinner: no printer is claimed for this kind of label, or the computer that owns it is not switched on. Two different problems with two different fixes, named as such.

Today's labels in one strip

The printer settings page shows what has printed today and what is still waiting, so "did that go through" is a glance rather than an investigation.

It repairs itself after a browser suspension

Browsers put idle extensions to sleep, which is exactly when an acknowledgement gets lost. On waking, on reconnecting, and on returning to the tab, the client walks its unfinished jobs and settles them against the server.

A failure interrupts the show, on purpose

When a job fails, a banner and a sound reach everyone on your team who is watching the stream, not only the person who fired it. Your moderator or co-host can see it and act while you are mid-show and cannot look.

Retry from the alert itself

The failure banner carries the retry button. You do not go hunting through a queue screen to find the label that did not come out.

Waiting is a visible state, never a silence

If no machine is live for the printer a job needs, the job waits, visibly, and prints when a station comes back online. It is never assigned to a machine that is not there, and never quietly dropped to keep a dashboard looking clean.

The same label never prints twice

The extension runs in two places at once, the popup and the show tab, and both used to dispatch the same job. A single elected leader now decides, so a job prints once. The server separately decides which surface is the live one, so the website and the extension can never both answer the same label.