What the diagnostics contain

Nothing leaves the device unless you tick the box

The support form has a checkbox for technical details. It starts unticked, and until it is ticked no bundle is even assembled on the device.

Beside it is a disclosure you can open. It shows the actual values that would be sent — not a description of them, not a summary. A consent screen that summarises what will be sent is a promise; one that shows it is evidence.

What is in it

Four groups, and this is the whole list:

When and what. The moment the bundle was taken, and the app version this device is running.

Offline capability. Whether this browser supports offline mode, whether a worker is actually driving the page you are on, which version of it is driving, and whether an update is installed and waiting to take over. During a release the version driving the page is the *old* one, and that is exactly the confusion a ticket usually needs settled.

Connection and queue. The link verdict — reachable, weak or down — whether the device is online, how many changes are queued, how many of those need a person, whether a sync is running right now, whether the device needs a sign-in, when it last synced, whether the browser has protected this site's storage from being cleared, the bill-block state, and how many bill numbers are left.

The last twenty errors the browser threw on this device, each trimmed to a short message and a short stack.

What is deliberately not in it

Not one queued bill. Not a line item, not a tender, not a customer's name or phone number, not an order identifier. And no money figure of any kind.

The count of bill numbers remaining is a count of numbers, not an amount. There is no rupee figure anywhere in the bundle, anywhere in a support ticket, or anywhere in the operator's view of one.

This matters more than it looks. The obvious version of a sync diagnostic attaches the queued rows, because that is exactly what you would want to debug a sync problem — and those rows are unsent bills with your customers' details in them. Sending those to a helpdesk while you believed you were sending "diagnostics" is the part that would be indefensible.

So the exclusion is enforced four ways rather than intended: the module that builds the bundle reads a published status object that structurally holds no such data, it is forbidden from even importing the queue's database, its shape is pinned key by key so widening it is a deliberate reviewed act, and the server discards the bundle if the box was not ticked even when a browser sends one anyway.

The error buffer

The twenty errors are held in memory on the device and nowhere else. They are not written to disk. Nothing sends them anywhere by itself — there is no crash reporter and no outbound call in that code at all. They leave the device only inside a ticket you submitted with the box ticked.

They do not survive a reload, which is why it is worth submitting the ticket from the tab where the problem happened rather than after restarting the till.

It keeps the last twenty, not the first twenty. The errors worth reading are the ones nearest the moment you gave up and opened the help menu.

What the ticket carries regardless

Separately from the bundle, a ticket carries the pathname of the screen you were on, your language, the app version, your browser and your screen size. The query string of that address is dropped for the same reason it is dropped everywhere else in the product: it routinely holds a customer's name or phone.

Your business, your plan and which modules you have on are resolved on our side rather than read from the browser — a browser that claimed a plan it did not have would otherwise write a false fact into a ticket somebody then acts on.

You do not have to attach it

Leaving the box unticked is a perfectly good choice. It makes the answer slower, not impossible — we will ask you questions instead.