We helped Albus Health make night-time monitoring reliable and stress-free.

How you sleep reveals a lot. Like if you’re likely to have a severe asthma attack in the next five days.

That’s the kind of insight Albus Health can unlock for patients and clinicians with their bedside monitoring devices. Which means those devices have to work all night, every night.

But that raises an obvious question…

Who monitors the night-time monitors? 

Catching data while you dream

Serious health problems rarely announce themselves loudly. They creep up quietly.

When it comes to breathing, the stakes are higher. Patients with asthma, chronic obstructive pulmonary disease (COPD), or rare paediatric diseases affecting oxygen intake can deteriorate gradually. Early signals can make the difference between early intervention and emergency care.

The good news is those signals exist.

Cough patterns. Breathing rate. Sleep disruption. The catch is that many of them show up at night.

Fortunately, if something goes bump, Albus will have the graph to prove it.

Their bedside device passively monitors patients overnight, recording more than a dozen physiological and environmental parameters, from heart rate to humidity. Then it uses AI to connect  the dots and raise the red flags clinicians need to act sooner, while supporting cutting-edge research in pulmonology, paediatrics, oncology and beyond.

Globally, the platform has already recorded over five billion data points. Participants don’t have to remember to press a button, the device just sits there and quietly does its job in the dark. 

Which is exactly why it needs to be boringly predictable.

That’ll be our cue, then.

Albus Health supports life-changing research and patient monitoring with its global fleet of cloud-based passive monitoring devices.

What keeps Albus Health awake at night?

Like many fast-growing health-tech platforms, Albus had strong engineers and deep system knowledge.

But some of that knowledge lived in heads, not systems.

Deployment processes were understood, but not always documented. Device logs existed, but searching them was manual and time-consuming. Troubleshooting often relied on knowing exactly which console to open and what pattern to look for.

In practice, the knowledge was in a few people's heads.

Which worked, until you needed to explain it to someone new, or move quickly.

Albus recognised they had to focus on three things:

1. Deployment confidence. Clarifying how source code is edited, reviewed and deployed.

2. Operational playbook. Extracting system knowledge from individuals and turning it into repeatable guidance.

3. Log visibility. Making device logs easier to search, interpret and act on.

So we headed to Oxford to work directly with the Albus team.

Step 1: Put tribal knowledge into a pdf. Make it routine.

At F12, we like a proper knowledge transfer. Not the wiki link kind. The real kind: laptops open, consoles live, and the uncomfortable questions that surface nuggets like: 

‘This is the bit people forget.’

‘This is the bit that breaks when you’re tired.’

‘This is the bit nobody wants to touch on a Friday.’

Credit to Albus, they were more than willing to go deep and the info we got was absolute gold. We put everything into a proper field guide for developers on-the-go, with clear actions like:

• how to get access cleanly (without Slack archaeology)

• what the key moving parts are—in human language

• how deployments happen when time is tight

• where the sharp edges are, and what “good” looks like

Step 2. Do more with device logs

Device logs are pretty dull. Dull, and crucial.

They’re time-stamped records of events, errors and system activity. In regulated health environments that’s not background noise, it’s evidence.

Handled properly, logs help teams:

• diagnose root causes quickly

• monitor performance across a growing device fleet

• detect unusual behaviour early

• support compliance and audit requirements

Albus already had tonnes of data.

The problem was scale.

Do you want engineers trawling through raw output? Or fixing issues quickly so they can refine AI models that detect breathing deterioration even earlier?

Exactly. 

We needed to make log analysis faster and more structured.

Enter OpenSearch

Something we are working on, that work is being led by Stuart Mackintosh, one of our AWS specialists and a hands-on engineer who genuinely enjoys chasing down strange log lines until they stop being ‘weird’ and start being ‘explained’. (To be fair, that’s most of us at F12.)

Outside work, Stuart brews a respectable IPA and plays a tidy game of snooker. On the job, that translates into patience, pattern-spotting and staying calm when the signal is buried in noise.

He’s currently leading the implementation of OpenSearch as the central home for Albus’ device logs.

The first priority is better troubleshooting and faster identification of unusual errors. From there, the goal is broader operational visibility across the platform.

Device log visibility? Hold my beer. And my cue.

The vital stats so far…

It’s early days, but by formalising deployment processes, strengthening observability and embedding structured support, we’ve helped Albus:

• reduce delivery friction

• increase operational resilience

• lowered dependency on individuals

• Increased observability of their system

Most importantly, clinicians and researchers can trust the platform to do its job overnight. 

Which means they can sleep a little easier.

Give your experts a night off

If your cloud platform relies on just one expert to function smoothly, let’s talk. We help teams document critical knowledge, boost observability, and build robust platforms that perform under pressure—so you can stop worrying about support gaps. Get in touch to start making your infrastructure resilient and predictable.

Boring, in the best possible way.