Nobody Should Drive Four Hours to Reboot a Server

Published: 2026-11-09•By Marc Straus
Nobody Should Drive Four Hours to Reboot a Server

It's 2:10 in the morning and a switch has gone quiet

Picture the scene. A network switch in a colocation facility three states away stops responding. Monitoring lights up. Your on-call engineer tries everything he can reach from his laptop, and none of it works, because the problem is physical. Something needs to be unplugged and plugged back in.

So now there's a decision. Somebody drives. Four hours there, four hours back, plus badge-in paperwork at a facility that may or may not have a human at the desk at 3 a.m. Call it a full day gone, a tired engineer, and an outage that lasted far longer than the fix did.

This is the exact moment that remote hands services exist for. Instead of sending your own person, you call a technician who is already in the building, tell them what to do, and the switch is back in ninety seconds.

Simple idea. The confusing part is everything around it — remote hands, smart hands, IMACD, on-demand, per-incident, bundled. Vendors use these words differently, and a few use them interchangeably on purpose. That is where companies end up paying for a service that does not actually cover what they needed.

This guide walks through what each one really means, what you should ask before signing anything, and where hardware maintenance fits into the picture. No jargon, no sales pitch. Just the plain version.

What remote hands actually means

Remote hands is an on-demand support service where somebody else's technician does the physical work in a data center so your team doesn't have to be there.

That's it. That's the whole concept.

It usually shows up in one of two places. Colocation providers offer it as an add-on alongside the space, power and cooling you're already renting from them. Independent support vendors offer it too, often across facilities they don't own, which matters if your equipment sits in several buildings run by different companies.

Here's where the word gets slippery. Ask ten vendors what remote hands means and you'll get two different answers.

Some use it to mean work done with no one onsite at all. A technician logs in, checks a console, pushes a configuration, and never touches the rack.

Others use it to mean a technician who is physically standing at your rack, acting as your eyes and hands, doing exactly what you tell them over the phone. They're not diagnosing anything. They're the body in the building.

The second meaning has become the common one, and it's the one that overlaps with smart hands. More on that in a minute.

The practical takeaway: never assume. When a vendor says remote hands, ask them to describe a ticket from start to finish. Who shows up, what are they allowed to touch, and what happens when the task turns out to be harder than expected.

What actually fills a remote hands ticket

The work is deliberately simple. That's the design, not a weakness. Remote hands exists to handle the small physical jobs that block everything else.

A typical scope looks like this:

  • Rebooting a server or power cycling a device
  • Plugging and unplugging cables, drives or modules
  • Checking a status light and telling you what colour it is
  • Confirming a cable is seated where you think it's seated
  • Reading an error off a screen you can't see
  • Basic configuration changes you walk them through
  • Hardware and environment monitoring
  • Receiving a shipment, unboxing it, and clearing the packaging
  • Reporting back on what they found

Virtualized environments get the same benefit in a different form. When a container or a virtual machine fails in a way that needs a host touched, remote hands can do that step without anyone travelling.

Notice what's missing from the list. Nobody is installing a new server. Nobody is running cable through a ceiling. Nobody is diagnosing why a storage array keeps throwing errors. Those jobs need a different skill level, and they usually sit under a different service name.

If your idea of remote hands includes any of those bigger tasks, you are picturing smart hands, and you should be pricing smart hands.

Why companies reach for it

Three reasons come up again and again, and they're all variations on the same theme: distance costs money.

You pay for what you use. There's no salary, no benefits, no headcount request, no justifying a hire to someone in finance. You open a ticket when something needs doing and you close it when it's done. For a company with equipment in four buildings and a team of six, that math works out quickly.

You stop sending people on round trips. The real cost of an onsite visit is rarely the travel invoice. It's the eight hours your senior engineer spent in a car instead of on the project that's already late. It's the outage that stayed open while he drove. Companies tend to underestimate this one because it never shows up as a line item anywhere.

You get reach you couldn't build yourself. Infrastructure is spreading out, not consolidating. Edge sites, regional facilities, branch closets, equipment inherited through an acquisition and now sitting in a building nobody from your team has ever visited. A vendor with technicians already distributed across those regions covers ground that would take you years and a lot of hiring to match.

There's a fourth reason people mention less often, and it's worth saying out loud. Remote hands lets a small internal team look like a much larger one. The engineer who would otherwise be unreachable for a day stays at his desk, available to everyone else, while someone else does the two-minute physical job.

How you get billed, and where the money quietly leaks

This is the section most people skip, and it's the one that decides whether remote hands saves you money or slowly annoys you.

Three billing models dominate.

Per incident or time block. You're charged in blocks — fifteen, thirty or sixty minutes, depending on the vendor. Good for occasional, unpredictable needs. The trap is the block size. If your vendor bills in sixty-minute increments and your typical job takes six minutes, you're paying for fifty-four minutes of nothing, every single time.

Monthly hours allowance. A set number of hours is included each month. Predictable, easy to budget, and the one most companies drift toward. Two questions decide whether it's a good deal. Do unused hours roll over, or do they vanish on the first of the month? And what's the rate on hours past your allowance — the same rate, or a penalty rate?

Subscription. A flat monthly fee, often described as unlimited. Clean on paper. Read what unlimited is attached to, because it's usually attached to a defined task list. Anything outside that list gets billed separately or gets refused.

Whatever the model, it lives in the service-level agreement. Read that document properly before you sign it, and read it with a specific scenario in your head rather than in the abstract.

Two more things worth checking that rarely make the sales conversation. How are after-hours and weekend calls priced, since those are exactly when you'll need the service most? And does the clock start when the technician reaches your rack, or when you open the ticket?

Knowing how you're billed is the difference between a service that pays for itself and one that generates an invoice nobody can explain.

Smart hands: when basic hands aren't enough

Smart hands is the same outsourced model with a better-trained person on the other end.

The technician isn't just following your instructions step by step. They have the background to understand what they're looking at and to handle work that has judgment in it.

That opens up a different class of task:

  • Installing and racking new equipment
  • Structured cabling and cable management
  • Component replacement and repair
  • Server builds and configuration
  • Troubleshooting that needs someone to actually think about the symptom
  • Decommissioning and clean removal

The line between the two services used to be clean. It isn't any more. Plenty of vendors have folded basic onsite work into their remote hands package, and some sell both under the single name "remote hands" because it's the phrase buyers search for.

So the honest answer to "what's the difference" is: ask the vendor, because the industry no longer agrees.

What has stayed consistent is the underlying split. Remote hands is about following instructions. Smart hands is about applying expertise. One is a pair of hands. The other is a pair of hands attached to someone who knows what they're doing.

Price follows skill, as you'd expect. Smart hands generally costs more per hour. Whether it costs more overall depends entirely on how often a basic ticket turns out not to be basic.

The cheat sheet

Print this, or keep it open during the vendor call.

Remote hands

Smart hands

Skill level

Basic, procedural

Specialist, trained

Who directs the work

You do, step by step

The technician, within scope

Physical presence

Varies by vendor — offsite or onsite

Onsite

Typical tasks

Reboots, cabling checks, swaps, visual verification

Installs, cabling, component repair, real troubleshooting

Buying model

On demand

On demand

Relative cost

Lower per hour

Higher per hour

Best for

Routine jobs and after-hours incidents

Complex, specialized or unfamiliar work

Main risk

Scope stops short of what you actually need

Paying specialist rates for simple jobs

One row deserves extra attention: who directs the work. With remote hands, if you don't know what needs doing, the service can't help you. Somebody on your side still has to diagnose the problem and give clear instructions. That's fine when the answer is obvious. It's a problem at 2 a.m. when nobody is sure what broke.

And then there's IMACD

IMACD stands for Install, Move, Add, Change and Dispose. It's the least glamorous acronym in the business and arguably the most useful one, because it covers the whole life of a piece of hardware rather than a single incident.

Break it apart and it's obvious:

  • Install — new equipment arrives, gets racked, cabled and brought online
  • Move — gear relocates to another rack, another floor, another building, another city
  • Add — capacity goes in: memory, drives, cards, nodes
  • Change — configuration, upgrades, swaps, refresh work
  • Dispose — old equipment comes out, gets wiped properly, and goes somewhere responsible

Where remote hands and smart hands are reactive — something happened, somebody go handle it — IMACD is planned work. It's what you buy when you're opening a site, consolidating two data centers after an acquisition, or retiring a generation of hardware.

That last letter matters more than it used to. Disposal isn't just hauling boxes away. There's data destruction to document, asset records to close out, and environmental handling that an auditor may eventually ask about. Companies that treat disposal as an afterthought tend to discover the paperwork gap at the worst possible moment.

If your next twelve months include a move, a buildout or a decommission, IMACD is the conversation to have. It's a different discussion from "who reboots things for us".

Questions to ask before you sign anything

There's no universal right answer here. The right answer depends on your estate, your team and your tolerance for a problem sitting open while someone drives.

Start with these, in this order.

What's actually in my environment? Single vendor or mixed? Any hardware past its warranty window? Anything running in a colocation facility where you don't control physical access? Mixed and aging estates need a higher skill level than a uniform, current one.

What does my colo provider already cover? If you're in colocation, some of this may be included or available as an add-on. Find out before you buy it twice. Then find out where their scope ends, because that gap is what you're shopping for.

How fast do I need a response, and does the contract say so? "On demand" is marketing language. A response-time commitment is a contractual one. Ask for the number, in writing, and ask what happens when it's missed.

Do I have the internal expertise to direct the work? Basic remote hands assumes somebody on your side knows what to tell the technician. If your team is stretched thin or the equipment predates half of them, you want more capability on the other end, not less.

What's the escalation path? The technician gets to the rack and the problem is bigger than expected. What happens next? Does the ticket stall, does it hand off to a senior engineer, or does somebody call you back for new instructions?

And what about the parts? This one gets forgotten constantly. Hands are useless without the component. If a drive has failed, who supplies the replacement, how long does it take to arrive, and is it stocked anywhere near your site?

That last question is where a lot of companies discover their remote hands contract solves half the problem.

Most teams end up with a mix, and that's the right answer

Nobody picks one model and uses it for everything. The companies that get this right split the work by what it costs them.

Your own team keeps the work that depends on knowing your systems. They understand the history, the quirks, the reason that one server is configured differently from the other eleven. That knowledge doesn't transfer to an hourly technician and you shouldn't try to make it.

Outside hands take the work that's really about being in the building. A reboot at midnight. A cable check at a site six hours away. A drive swap in a facility your team visits twice a year.

The split is usually drawn along distance and time of day. Close and during business hours, your people go. Far away or at 3 a.m., somebody else goes.

Two cautions, both worth saying plainly.

Sending your own team out always looks cheaper than it is. The travel invoice is the small part. The real costs are the extended outage, the day of lost project work, and an engineer who's worn down by the third late-night drive of the quarter.

And outsourced hands are only as good as the scope you bought. A vendor who isn't contracted for complex work won't do complex work, regardless of how urgent it feels at the time. A response-time promise with no teeth in the SLA is a sentence on a website.

Pick the vendor carefully, read the scope, and be honest about what you're keeping in-house.

The question underneath all of this

Here's something the hands conversation tends to skip.

Every service in this article assumes your hardware is supported. Somebody sends the part. Somebody takes the call when the array throws an error at 4 a.m. Somebody is on the hook when a component fails.

For equipment still under manufacturer warranty, that's handled. For equipment past it, it often isn't — and this is where a lot of companies quietly end up exposed.

The pattern is familiar. The warranty ends. The renewal quote arrives and it's higher than anyone expected. The hardware is running fine, nobody wants to refresh it early, so the renewal gets pushed to next quarter. Then the quarter after that. Now there's working equipment in production with no support behind it, and the fastest technician in the world can't fix a failed drive without a drive.

That's the gap we work in at ETS. We provide post-warranty maintenance on servers, storage and network equipment — the layer underneath the hands — along with IMACD work across the hardware lifecycle: installs, moves, adds, changes and disposal. When manufacturer support ends on hardware that's still doing its job, there's a third option besides renewing at OEM prices or refreshing before you're ready.

It's worth being clear about what maintenance is and isn't. It covers support and parts for existing equipment. It doesn't make slow hardware faster, it doesn't prevent every outage, and it doesn't automatically carry manufacturer software or firmware entitlements. What it does is keep suitable equipment supported and in service, usually at a lower cost than the renewal sitting on your desk.

If you're reviewing your onsite support strategy anyway, it's a good moment to pull up the warranty dates alongside it. The two questions belong together: who are the hands, and who is behind them.

The short version

If you read nothing else, read this.

Remote hands is somebody else's technician doing simple physical work so your team doesn't travel. Smart hands is the same model with a skilled technician handling complex work. IMACD covers planned lifecycle work: installs, moves, upgrades and disposal. The three overlap, vendors define them differently, and the name on the brochure tells you almost nothing.

So ask for the scope in writing. Ask how you're billed and what happens when a ticket runs long. Ask who supplies the parts. And check your warranty dates while you're at it, because hands without support behind them only solve half the problem.

Getting the combination right isn't complicated. It just takes asking a few specific questions before you sign rather than after something breaks.

If post-warranty maintenance is the part you haven't sorted out yet, that's what we do at ETS. We support servers, storage and network equipment after manufacturer support ends, so you can keep good hardware in service without the OEM renewal price or an early refresh.

Happy to take a look at what you're running and tell you straight whether it's worth covering. No obligation either way.

Get in touch →