If you use a health app to remember appointments, track steps or open a report from your hospital, you have already depended on the quiet work of a reliability team, even if no one ever told you. The field goes by the initials SRE (site reliability engineering), and it comes with a pile of half-true folk stories. Here are half a dozen of the stories I hear most, taken one at a time over a metaphorical cup of tea. This is general technology reading for curious readers of a digital health blog, not medical guidance of any kind.
Everything factual here is drawn from the Ops Atlas, an online reference that carries an entry on the subject. Where I describe how it frames something, I will say so, and I will keep the jargon light.
Myth 1: “SRE is just the old support team with a trendy name”
It is a very common suspicion, and sometimes it is even right, but only about bad implementations. The Atlas has a label for a renamed support desk: a counterfeit version of the discipline. A real reliability team does something different: it sets measurable promises, tracks them, and limits the amount of repetitive manual work its members do. Think about your reminder app. A support team answers you when the reminders fail. A reliability team works out how often reminders fail, decides how often is acceptable, and builds the machinery so that the failure rate shrinks over time.
Myth 2: “The goal is to never go down”
Honestly, it would be lovely if that were achievable, yet the Atlas takes the opposite position. Its argument is that aiming at flawlessness misleads almost every team, because every extra step towards it gets dramatically more expensive and slows everything else. The more useful question is how much trouble users will tolerate. If your heart-health diary app failed to sync one entry in a thousand, would you stop using it? Probably not. If it failed one in five, you would. The skill lies in finding the honest middle and writing it down.
Even better, the Atlas treats the gap between the promise and perfection as a budget that can be spent. When plenty is left, the team can try new features. When it is nearly exhausted, they put the new things on hold and shore up the old ones. Reliability gets spent on purpose, which is a healthier habit than treating each outage as a scandal.
Myth 3: “SRE just means watching dashboards”
Watching is one part of the picture, and in the Atlas’s own map the detailed craft of telemetry sits in a neighbouring discipline. What SRE adds is the decision layer: which numbers represent happy users, what the promise is, and what happens when the promise is broken. A dashboard full of lines is not a plan. Imagine a fitness tracker with fifty graphs and no idea which one says your step count is wrong. The count of good outcomes among valid attempts, measured from the person’s side of the screen, is the number that tends to matter.
Myth 4: “Developers get to go home while the reliability people carry the pager”
Nope. According to the Atlas, the opposite instinct is baked in. When operational chores pile up past a healthy share, the work is pushed back to the developers who built the system. The cap, as it describes Google’s guideline, is that repetitive chores should stay under half of the team’s time. A cap with no consequence is just a wish, so the Atlas says it needs teeth, such as redirecting tickets or bringing developers onto the rota. Think of it as a household where everyone does the washing up, not only whoever notices the pile first.
Myth 5: “A blameless review lets everyone off the hook”
This one deserves a gentle correction. A blameless review simply avoids pointing at a person as the cause, because people working in complicated systems tend to make reasonable choices with the information they have. What the practice demands is rigour about the follow-up: concrete tasks, named owners, deadlines. The Atlas is clear that this is strict about actions even as it is kind about people. Compare it to how a good family handles a missed medication reminder: you do not scold the person, you fix the routine so it is harder to miss next time.
Myth 6: “More alerts equal more safety”
It feels logical that the more warnings you have, the safer you are. In practice, a constant stream teaches everyone to ignore them. Among the recurring mistakes the Atlas counts raising an alert for each and every metric, and it describes a smarter approach in which a person is woken only if the budget is draining fast. For a slow leak, a ticket is enough for the next working day. If your phone pinged you for every tiny movement of your pulse reading, you would switch notifications off, and the one alert that mattered would be lost with the rest.
A small bonus: the quiet wisdom behind the numbers
One of my favourite details in the Atlas is a story about an internal Google service that was deliberately switched off for short planned periods. The reason was not mischief: the service had been so dependable that other teams had started to assume it would never fail, and the planned gaps flushed out that over-reliance. It is a charming reminder that dependability can breed complacency. Digital health services deserve the same suspicion towards their own track records, especially the ones that have worked well for years.
What this means for you as a user
You do not need to run a reliability team to benefit from the mindset. A few questions will serve you when choosing or using a digital health service. Does the provider say how often it expects things to work? Does it explain what happens when something breaks? Do they tell you what they fixed afterwards? Answers to these say nothing about how good the care itself is, since that is a question for your doctor, but they hint at an organisation that treats its own systems seriously.
If you would like the technical background in full, the Atlas has a very long entry, which you can find as an in-depth reference on SRE principles and practices. It is dense, but the sections on objectives and budgets are readable for newcomers.
More from this blog
Readers who enjoy the engineering side of healthcare may like a post about how an Indian technology firm approaches engineering discipline and digital ecosystems. For a very different, strictly educational angle, a reference-style article on a cardiology functional class scale shows how clearly defined categories help people talk about complex things, a bit like a good objective does for software. As always, nothing here replaces a conversation with your own doctor.
The short version
Reliability is not about heroics, never failing or staring at charts. It is about choosing a sensible promise, counting honestly, spending the allowance wisely and learning kindly from mistakes. The next time your health app opens quickly and reminds you at the right moment, spare a thought for the unglamorous routines that made that boring, which is exactly what you wanted.
