How we think about reliability

Most software can go down for an hour and the cost is a backlog: work piles up, people catch up later, and nothing is really lost. A point of sale doesn't get that grace. When it goes down during business hours, a line forms at the counter, your team can't look up a price or pull up an account, and some of the customers in that line set their things down and leave. The sale walks out with them, and the impression of a store that couldn't help them stays behind. Running your store on Rundoo means trusting us with the most operationally critical system you have, and this is what we do to be worthy of that.

Not every outage costs you the same

We rank failures by what they actually cost your business, and we spend our engineering effort accordingly:

1. A sustained outage during business hours. This is the one we treat as close to unforgivable. Fifteen minutes of downtime during the morning rush costs you sales and goodwill at the same time, and nearly everything on this page exists to prevent it.
2. A blip of under a second. You tap again, it goes through, and your customer never notices. We work to eliminate these too, but they don't cost you a sale.
3. An outage overnight while the store is closed. Frustrating if you're counting inventory at midnight, but it never touches a customer.

There's a fourth failure that doesn't start on our side at all: your store's internet connection going out. Nick covered how Rundoo handles that in Where is the offline mode?

Standing on proven infrastructure

The first reliability decision happens below our own code. Rundoo runs on Google Cloud, the same infrastructure that runs Gmail and YouTube, which means the work of keeping servers powered, networked, secured, and replaced when they fail is done by one of the largest infrastructure teams in the world rather than by us. That work is invisible when it's done well, and Google does it at a scale and a level of rigor that no point-of-sale company could match on its own.

We make the same choice one level up. Your data lives in Google's managed database service, which backs it up continuously and lets us restore it to the way it was at any specific minute. Whatever else goes wrong on a bad day, your sales history, inventory, and customer balances are never part of the blast radius.

Preventing bad changes from reaching your store

Most outages in software have the same root cause: somebody changed something. Reliability work therefore starts with how changes are made.

1. Testing. Before any change reaches the system that runs your store, it has to pass thousands of automated tests. Every new feature also ships with its own tests attached, so a change someone makes a year from now can't quietly break it without a test failing first.
2. Small, frequent changes. As of June 2026 we ship 20 to 30 updates a day, each one deliberately small. When something does go wrong, the responsible change is tiny, recent, and easy to find. Much of our industry still ships software in large quarterly releases, where every problem becomes a search through months of accumulated changes.
3. Gradual rollouts. Higher-risk changes, especially anything involving money, don't turn on for everyone at once. We enable them for a small number of stores first, watch how they behave, and only then expand. If something is wrong, we learn it from a handful of stores instead of all of them.

Catching and fixing the ones that slip through

No prevention is perfect, so the second half of the work is finding problems fast and fixing them fast.

1. Monitoring. Automated checks run against our live system around the clock, confirming the product is responding and responding quickly, so we typically know something broke within moments of it happening. Customers report problems too, and we're grateful when they do, but the goal is to already be working on a fix before anyone picks up the phone.
2. Redundancy. The systems your store can't operate without run as multiple copies. If one fails, traffic moves to a healthy one, usually without you noticing anything happened.
3. Rollback. Because every change is small, undoing one is small too. When a bad change reaches production, we roll it back quickly and cleanly, often automatically.

No one is perfect, including us

Even with all of this, we won't promise you that Rundoo will never have a bad minute, because nobody can promise that honestly. Google Cloud and Amazon Web Services run the most sophisticated infrastructure operations on the planet, and both still have the occasional outage that takes a visible slice of the internet down with them. What we can promise is the discipline that makes a bad day rare and the machinery that makes it short. We understand exactly what's at stake when your register is the thing standing between a customer and the door, and on the rare day we fall short, our job is to be back before your line is.