How I keep Surya Host running

I started Surya Host in 2022. I was seventeen. My first customer was a friend who needed a WordPress site for his father's furniture shop. I charged ₹800 a month. He paid on time. I didn't sleep much that first week, checking whether the server was still responding.

Three years later I have a few dozen customers — small businesses, personal sites, a couple of NGOs, one school. The prices haven't changed much. The sleep has improved. The anxiety hasn't fully gone away, but it has become productive.

What 99.9% actually means

99.9% uptime is 8.7 hours of downtime per year. Across all customers, I aim to stay well under that. In practice the sites I host are down maybe 15–20 minutes a year, usually during planned maintenance windows at 2 am on Sunday. That's the goal. Not because a number in a contract demands it — I don't have contracts with most of my customers — but because a furniture shop owner loses actual business when their site is down.

The real cost of downtime for a small business is not the downtime itself. It's the trust that drains quietly when a customer tries to find your phone number and sees a server error instead.

The setup

I run a small cluster of VPS instances — two in Mumbai, one in Bangalore, and a tiny Frankfurt node that handles EU traffic for one international client. None of them are fancy. 2 vCPUs, 4 GB RAM is my standard config. Nginx in front, PHP-FPM for WordPress sites, Node.js for everything custom. Each server has monitoring through UptimeRobot (free tier) and a paid Grafana Cloud instance that I pay for out of pocket because pretty graphs help me explain things to customers.

# Quick health check across all nodes
for host in mumbai-1 mumbai-2 bangalore-1; do
  echo "=== $host ==="
  ssh $host "uptime && df -h / && systemctl is-active nginx php8.2-fpm"
done

Every morning I run a simple check before anything else. If something looks wrong I deal with it before customers wake up. This sounds basic because it is basic. You don't need elaborate automation when you know your systems personally. I know exactly which site is on which node, which customer pushes a lot of traffic on weekends, which WordPress installation hasn't been updated in four months because the owner is afraid of breaking something.

The 11 pm call

One of my customers runs a travel agency. Last October she called me at 11:17 pm on a Saturday. Her booking enquiry form had stopped sending emails. She had three enquiries sitting in the database that she didn't know about. A family had been waiting two days for a reply.

The fix took eleven minutes. A PHP mail configuration had quietly broken after a server package update. I updated the SMTP config, tested it, sent her a test email, and stayed on the call while she checked her inbox. She thanked me and apologized for calling late. I told her to call any time.

That's the job. Not uptime percentages. That family got their trip sorted.

What actually breaks

In three years of running this, the failure modes are always the same: disk fills up, memory leaks in a long-running PHP process, SSL certificates expire because someone changed a DNS record and broke the auto-renew, MySQL slow queries killing a shared node, a WordPress plugin update that introduces a PHP fatal error. None of this is exotic. It's all predictable if you watch for it.

# Runs at 6am daily — alerts me if any mount is over 80%
df -h | awk 'NR>1 && $5+0 > 80 {print $0}' | \
  while read line; do
    curl -s -X POST "$TELEGRAM_WEBHOOK" \
      -d "chat_id=$CHAT_ID" \
      -d "text=DISK ALERT on $(hostname): $line"
  done

I get a Telegram message if any disk hits 80% full. I've never had a disk-full incident since I set this up. Before that, I had one. One was enough.

The thing I'd tell myself in 2022

Don't oversell on price. Oversell on knowing people's names. If a customer knows that you know their site matters to them — to their real business, not just as a line item on a server — they will forgive the occasional fifteen-minute outage. They won't forgive feeling like a ticket number.

Surya Host isn't large. It might never be large. But every site I host is someone's actual livelihood, and that responsibility is what keeps me checking servers at 6 am. Not ambition. Obligation.