The One Test Nobody Runs Before They Sell Tickets

You have opened your own event page and watched it load.

You have almost certainly never bought a ticket from it yourself, with a real card, and waited to see if the confirmation email landed.

Loading is the easy test. Selling is the one that matters, and it is the one almost nobody runs.

We found that out about our own platform, in the worst possible direction. It wasn’t a page that failed to load. Every page loaded. Every domain answered. The listing looked exactly as it should. What we hadn’t checked, in over a month, was whether a sale could actually finish.

What “working” was quietly resting on

Our production database had missed eleven updates in a row.

Each update adds something the system needs to do its job: a table, a column, a rule. Skip enough of them and the parts that record a sale don’t exist yet. Ours was missing the piece that stores who paid, the piece that stores the payment record itself, and the piece that sends the ticket by email.

Not slow. Not buggy. Structurally unable to finish a transaction, whatever anyone had configured on top of it.

For five weeks, the only row in that database was one ticket we had bought ourselves, to prove the page worked. It did. Once. Nobody had bought since, and for most of those weeks, nobody could have.

In our defence, nothing on the page said so. It just quietly declined to work, forever, without raising its hand.

The gap between “it loads” and “it works”

This trap isn’t ours alone.

A URL answering tells you a server switched on. It tells you nothing about the database underneath it, the payment processor behind that, or the email meant to follow. Every one of those has to work, in order, before a stranger ends up holding a ticket. Checking that the page loads tests one link in a four-link chain and calls it done.

You almost certainly have a version of this somewhere in your own setup:

• The registration form you built in the spring and haven’t personally submitted since.
• The badge scanner you tested on your own phone, on your own wifi, standing still - and not on someone else’s phone, on 4G, in a queue.
• The confirmation email you’re confident goes out, because it went out that one time you checked.

How we caught it, and what we changed

We found ours by accident, recovering a note that had been written down once and then lost rather than acted on.

Once we saw the gap, we didn’t guess. We checked the database directly, not the dashboard sitting on top of it. We read every missing update line by line for anything that could destroy data, took a full backup before touching a thing, and only then ran the update.

Even confirming the fix, we didn’t take the tool’s word for it. We queried the database ourselves and counted the tables by hand. That is the small habit that would have caught the original problem five weeks earlier: don’t check the thing that reports it’s fine, check the thing itself.

The part worth keeping isn’t the fix. It’s that we built something to make the same mistake structurally impossible to repeat. The system now refuses to update a database from instructions that don’t match what’s actually meant to be live, and it refuses by default rather than assuming the best. If it can’t check, it says no. A shrug is how we ended up here, and a shrug is no longer one of its options.

The test that would have caught it

One test would have found this weeks earlier: buy a real ticket, with a real card, on the real domain, and see if the confirmation email lands.

Not a dashboard glance. Not “the page loads fine.” A completed sale, with a stranger’s money on one end and a ticket in an inbox on the other.

If you run events, you have a version of that test sitting undone somewhere in your stack. The honest move is to go and run it today, on your own page, with your own card.

Loading is not working. The only proof of working is a sale that actually finished.