- For a shared core, uptime matters more than peak spec — an instrument that's down for a week waiting on a service visit fails the labs depending on it, however well it runs when it's working.
- Self-sufficiency is what protects that uptime: when the core can install an instrument over a call and handle routine upkeep in-house — fluid and filters in minutes — the everyday running of the core doesn't wait on a service schedule.
- A service contract is standard and sensible; what varies is how much of the everyday upkeep still depends on it — the less routine maintenance that needs a service visit, the more uptime the core controls.
A shared core can't afford a front end it can't fix itself
In a single-lab setting, an instrument going down is one group's bad week. In a shared core, it's everyone's. The disruption and extraction step is the one every sample passes through before it reaches a mass spec or a sequencer — so when that front end stops, the whole queue stops with it, proteomics and genomics projects alike, and "the part is on back-order, the engineer can come Thursday" becomes the core's problem to explain, over and over.
That's why dependability, for a shared front end, isn't really about how rarely something breaks. It's about how fast the core can get it running again without waiting on someone else. An instrument only the vendor can service is an instrument whose uptime the core doesn't control.
On a shared instrument, downtime is never one lab's problem — it's the whole queue's.
Self-sufficiency starts at install and continues through maintenance
This is where the practical design of an instrument matters more than its headline spec. PIXUL was built to be run by the lab that owns it, not by a visiting engineer. It installs over a call rather than a scheduled site visit, and the routine upkeep is the kind a sonicator actually needs — changing the fluid and the filters, done in minutes by the people already running it, not the optical alignment or specialist calibration that forces an engineer on-site. The day-to-day stays in the core's hands rather than on a service schedule.
That changes what "maintenance" means for the core. Instead of logging a ticket and waiting, the person at the bench handles it and keeps the queue moving. Uptime stops being something the core requests and becomes something it controls.
A service contract isn't the question — how much rides on it is
Most instruments carry a service contract, and most cores will and should have one — it's the sensible backstop for the rare, genuinely complex fault. So the useful question isn't whether you're covered. It's how much of your routine uptime depends on that coverage.
There's a real difference between a contract that sits in reserve for the occasional serious fault and one you have to invoke for everyday upkeep. The more of the day-to-day — the fluid, the filters, the routine maintenance — your own team can handle at the bench, the less often "being covered" is the only way to get the instrument running again. The contract is still there; it just isn't what stands between the core and its next run.
In-house maintenance means minutes, not a second job
Does maintaining the instrument in-house add real work for your team?
No — the routine upkeep is a fluid change and a filter swap, done in minutes by the people already at the bench. It keeps that everyday upkeep from becoming the larger hidden task — raising a ticket, scheduling a visit, and explaining the delay to the labs in the queue — every time something routine needs attention. Self-maintained doesn't mean more work; it means the work is short, in your hands, and over quickly (dependable enough to build a facility around?).
Evaluate who has to be on-site, not just what the instrument does
Most front-end evaluations stop at capability — what the instrument runs, and how well. For a shared core, there's a second column that matters just as much: who has to be present for it to keep running. Add it to the comparison (the full evaluation framework lives in the pillar). The instrument your own team can install and maintain is the one that keeps the core's commitments when something inevitably needs attention.
