When something breaks mid-service, the till should say what
A bare “500” tells the person running the floor nothing. A useful error log names the screen it happened on, counts how often, and puts the worst first — so the owner can act on it instead of waiting for a customer to report it.
Every system breaks somewhere eventually. The difference between a system you can run a business on and one you cannot is not whether it fails — it is whether, when it does, the person standing at the counter can find out what and act, or is left staring at a spinner while a queue builds.
The worst version of this is the error that only the customer sees. A screen quietly fails to save, the staff member assumes it worked, and the first anyone hears of it is a complaint an hour later with no way to trace what happened. An error that reaches nobody who can fix it is, operationally, an error that did not get reported at all.
What a useful error says
So the error log earns its place by being specific. Not "something went wrong" but which screen, which action, and — the part that turns noise into a work list — how many times. A fault that has happened once since Tuesday and a fault that has happened fifty times today are different problems, and a log that shows them as one line each, worst first, tells the owner which one to care about this morning.
A worked example
Recently a single line in that log read like this: one screen, saving one kind of record, failing every time it was tried, three times, all yesterday. That specificity was the whole fix. It pointed straight at one save that had been quietly broken — listing one more field than it actually filled in — so it could be found and corrected in minutes rather than waiting for the member of staff it was failing to give up and phone. An error that names the screen is not a nicety. It is the difference between a bug you fix before lunch and one you discover from an angry review.