In 1999, I wore a pager.
Not because I was a doctor or worked in some high-stakes operations center. I wore it because I was 22, working at Ogilvy in Washington, DC, and I had made the mistake of teaching myself HTML. That made me "the computer guy." And being the computer guy meant that when websites went down—which was constantly—I needed to know.
The pager was a SkyTel, clipped to my belt like a small bomb waiting to go off. We paid a company to monitor our clients' websites and send me an alert when they stopped responding. The alerts came often.
Servers in those days went down the way cars used to break down in the 1970s: regularly, unpredictably, and with a kind of resigned acceptance from everyone involved.
There was no GoDaddy back then. No Bluehost, no one-click WordPress installs, no cloud. If you needed to host a website, you would find a company that would rent you a physical server—an actual machine on an actual rack in an actual building. It came with nothing. No security patches, no firewall, no automatic backups. You wanted a firewall? That was a separate appliance you rented. Bandwidth was capped, sometimes as low as a few gigabytes a month. You chose between Windows and Linux, and if you chose Windows, you paid Microsoft's licensing fees on top of everything else.
I did ColdFusion development for a while. That meant a Windows Server license, then a ColdFusion license on top of that, then hoping the whole stack stayed upright long enough for clients to see their websites. Companies paid hundreds of dollars a month for hosting and called on landlines when things broke.
Nobody called to complain about slow sites. They were all slow. You were lucky if the site even loaded.
When a Utility Crew Took Out Silicon Valley
In 2001, I was working for a PR firm in San Jose, building what we called "interactive media rooms" for companies like Hewlett-Packard and various dot-com startups that wouldn't exist a year later. One day, our sites went dark. I called the hosting company and learned that a city utility crew had cut through the main internet line.
It would take a day or two for things to come back online.
I got fewer panicked calls that week than I do now when a site is down for ten minutes.
That was the baseline. Downtime wasn't an emergency; it was weather. You planned around it. You hoped for the best. When things broke, you fixed them or waited for someone else to fix them, and everyone understood that this was just how it worked.
The Time I Left a Downed Server to Buy a Book
Around 2002, I was still working for someone else—and I had probably told them I knew more than I actually did.
When a server went down, and I didn't know how to fix it, I had no real options. This was before Google was useful for technical questions. Before forums had critical mass. Before Stack Overflow existed. I practiced on GeoCities and figured things out on my own because there wasn't really another way.
So when something broke, and I was stuck, I did the only thing I could: I drove to Barnes & Noble, found the technical section, and hoped the index of some book on Windows Server or ColdFusion would point me toward an answer.
I remember standing in that aisle, flipping through pages while a server sat down, thinking This can't be how everyone does this.
It wasn't, of course. Most people didn't do this at all. The web industry barely existed. Those of us building it were making everything up as we went.
The Basement in Arlington Where My Server Lived
I didn't last long as an employee. By 2004, I was running my own operation, which meant the hosting bills and the server headaches were mine to own.
By 2009, I had been doing this for a decade. I could write bash commands, troubleshoot Linux issues, navigate Windows DLLs—most of it learned the hard way, often during outages, sometimes by crashing things and paying IT consultants to help me understand what I'd broken.
But the infrastructure was still fragile in ways that seem almost unbelievable now.
That year, I was on a family trip when a cluster of client sites went offline. The hosting company traced it to a failed hard drive—an old spinning disk that had finally given out. While they worked on replacing it, they accidentally fried the power supply. There were no automatic backups. I spent days piecing things back together.
But here's the part that feels almost quaint now: that server was a physical machine that I had actually visited. It lived in the basement of a building in Arlington, Virginia. I walked into that room, saw the racks, heard the hum of the cooling systems, and pointed to the box that held my clients' websites.
There was no cloud to migrate to. No VM to spin up on a healthier host.
That was my machine, and if it didn't work, my business didn't work. I had to fix it because there was no other option.
Two Servers, Not One
I started FatLab in 2011. For a single guy formalizing a web business, the startup costs were high: two physical servers and a load balancer from Rackspace. Each machine had maybe 40GB of storage and 4GB of RAM, which at the time felt substantial.
I marketed the redundancy—"two servers, not one"—because reliability was the differentiator.
It was also a headache. I spent what felt like a quarter of my working hours on the phone with Rackspace support, troubleshooting issues, and coordinating fixes. Mirrored MySQL databases became possible, and I jumped on them because the economics had shifted enough that you could build reliability through duplication rather than just hoping your single machine would hold together.
Around that time, Google announced that page load speed would factor into search rankings. Suddenly, performance wasn't just about user experience; it was about business outcomes.
The expectations kept rising.
The First Time I Had an Actual Answer
In 2012, I sat in a client meeting to discuss their website strategy. Inevitably, they brought up a recent outage. "What can we do," they asked, "to make sure this never happens again?"
I laughed because the question was still somewhat absurd. Hundred percent uptime wasn't realistic.
But for the first time in my career, I had an actual answer: redundancy. Multiple servers. Failover systems. Load balancing. It wasn't a guarantee, but it was a strategy—something beyond "hope the machine doesn't break."
That felt like a turning point. We had moved from managing chaos to engineering against it.
When Hosting Became Invisible
By 2015 or so, the landscape had shifted dramatically. Virtual machines weren't a premium feature anymore; they were the default. Companies like Digital Ocean and Vultr offered private VMs in the cloud—you could choose your data center. Still, you'd never visit your server because it could be running on any physical host in that region on any given day.
Hard drive failures became someone else's problem. If a provider detected a failing disk, they'd migrate your VM to healthy hardware without even telling you.
The whole concept of "your machine" started to dissolve.
Meanwhile, GoDaddy and Bluehost raced to the bottom on pricing. Hosting became a commodity, which meant companies like mine could differentiate by offering actual service—managed WordPress hosting, security monitoring, and expert support. Providers like Kinsta and WP Engine emerged, offering scalable resources and robust support infrastructure.
Cloudflare puts firewalls at the edge. Sucuri offered security as a service. SSDs replaced spinning disks. Containerization meant that a problematic site could take down its own container rather than crash an entire server. Self-healing infrastructure became real. Backups went from "something you should probably set up" to automatic and invisible.
DDoS attacks, which would have devastated us in the early days when we had literally nothing to stop them, became manageable through edge security services.
The whole stack got more stable than I ever would have imagined in 1999.
The Dinner I Almost Didn't Have to Leave
Today, when something goes wrong, it's usually at the cloud or data center level—not at the individual server level. This is a double-edged sword. I spend far fewer nights and weekends tuning servers, but when there's an outage, I often have very little control over how it's fixed. I check a status page. I make a phone call. I communicate with anxious clients whose sites have been down for five whole minutes. We've traded the chaos of the patchwork era for dependency on an oligopoly.
My role shifted from firefighting to strategy. Server stability used to be half the job. Now it's security, software updates, protocol development, and client communication. WordPress releases updates weekly. Plugins need constant attention.
The complexity moved up the stack—away from the infrastructure and toward the software layer.
In 2022, I had to excuse myself from dinner with my wife and friends to deal with an outage. My wife started in on the familiar complaint: This always happens, you're always working.
I stopped her. "Think about it," I said. "This has happened maybe twice this year. Remember when it was every week?"
She paused. "Oh wow. You're right."
When I got into hosting in 2000, I was on call more than an ER doctor. Now the infrastructure has gotten reliable enough that the interruptions are rare—annoying when they happen, but rare.
What Barnes & Noble Taught Me About Troubleshooting
Everything I learned the hard way still matters. Writing terminal commands, setting up Docker containers, and understanding Linux at a deeper level than point-and-click—that's what lets me solve problems faster than anyone I know.
I may not be the best developer, but I can troubleshoot.
Nothing frustrates me more than developers who can only install plugins through a browser interface and don't understand how computers actually work. The foundational knowledge—the stuff I picked up from physical books, crashed servers, and desperate problem-solving before Google was useful—that's what makes modern work possible.
It's less about dealing with outages regularly now and more about understanding what to do when one happens, where to look, and what to tell my clients. It's about strategy and protocols, not reactive firefighting.
Standing in that Barnes & Noble aisle in 2002, I was just trying to get through the day without getting fired.
I didn't realize I was building the foundation for a career.
If That Hard Drive Failed Today
If the 2009 hard drive failure had happened today, I probably wouldn't have known about it.
Our hosting provider would receive a health alert on the drive before it failed. They'd migrate the VM to a different physical host with no downtime. They might not even notify me, because I don't actually know which machine my sites are running on. I know the data center is in a particular region, but the specific hardware? That's abstracted away entirely.
The server I visited in that Arlington basement—the one I could point to and say "that's mine"—doesn't exist anymore. Not conceptually, anyway. My clients' sites live on a cluster of machines that shift, heal, and migrate without my involvement.
That's the whole point.
Twenty-five years ago, hosting a website meant renting a machine, hoping it stayed running, and wearing a pager in case it didn't. Today, it means trusting infrastructure you'll never see to handle problems you'll never know about.
I don't miss the pager.
But I'm glad I wore it. Everything I learned in that era—the patience, the troubleshooting instincts, the deep understanding of what's actually happening beneath the interface—that's what makes me good at this job now, in an industry that looks nothing like the one I stumbled into at 22.