A Day in the Life of a Remote SRE / DBA (Working from Edinburgh)

Working remotely as an SRE or MSSQL DBA can look deceptively quiet from the outside, until it isn’t!

I work fully remote from Edinburgh as a Senior SQL Server DBA / SRE, supporting production systems used by internal engineering teams across multiple time zones. This post walks through a typical day: how I start my mornings, what I actually monitor, how on-call works, the tools I rely on, and how remote work fits around parenting and real life.

---

Contents

• Starting the Day: Consistently at 9am
• What a SQL DBA Actually Monitors
• Meetings, Incidents, and Context Switching
• On-Call and the Follow-the-Sun Model
• Tools I Use Every Day
• Working From Home in Edinburgh
• Parenting, Flexibility, and Boundaries
• Staying Productive Without Burnout
• Advice for Junior Engineers
• What People Underestimate About SRE / DBA Work
• What I Wouldn’t Trade

---

Starting the Day: Consistently at 9am

9am is almost a religious start time for me.

I work alongside three engineers based in India, so by the time I log in there’s already momentum. That overlap is intentional, it gives us coverage and clean handovers (if necessary).

If anything is red, something needs attention. If not, I move on to pending requests, changes awaiting review, or project work already in progress.

You can’t do good work until the foundations are solid. I sometimes call this finding your food.

---

What a SQL DBA Actually Monitors

Most of my job is about protecting production databases before anyone else notices there’s a problem.

Everything else comes after that.

We also support internal customers across the business — software engineers, storage teams, networking, identity services. If their work touches SQL Server, there’s a good chance we’re involved somewhere along the way.

When systems are quiet, it’s rarely luck.
It usually means monitoring, automation, and preventative work are doing exactly what they’re supposed to do.

---

Meetings, Incidents, and Context Switching

Meetings are deliberately kept light.

The aim is simple: meetings should support the work, not replace it.

When something serious happens in production, we escalate quickly. Major incidents trigger a Global Operations Call (GOC) on Teams, bringing the right people together to stabilise systems and coordinate fixes. Thankfully, that’s the exception rather than the norm.

Most communication happens asynchronously, messages, tickets, and handovers; which works well in a company built around globally distributed teams.

Context switching is the hardest part of the role, and also one of the most important skills to develop.

It’s rarely one big problem at a time. It’s many small, unrelated ones, often arriving without warning.

When there’s unexpected free time, it goes straight into automation or longer-term improvements. That quieter work is where systems actually get safer, even if no one notices it immediately.

---

On-Call and the Follow-the-Sun Model

On-call duties rotate every five weeks:

• one primary week (Monday to Monday),
• followed by a lighter secondary week.

Being on call means responding to alerts when something breaks outside normal working hours. Most of the time, those alerts never arrive — which is exactly the goal.

I’m the only engineer based in Europe, so my time zone plays an important role. During UK working hours, I pick up alerts even when I’m not on call, which helps avoid waking teammates in other regions or interrupting evenings unnecessarily.

It’s not about doing more hours, it’s about making the follow-the-sun model work properly. When each region covers its natural daytime, incidents get resolved faster and the overall load stays sustainable for everyone.

---

Tools I Use Every Day

I don’t rely on anything particularly flashy, just a small set of tools used deeply and consistently.

• SQL Server Management Studio (SSMS)
  Still the core of day-to-day MSSQL work, from troubleshooting production issues to validating changes.
• VS Code
  Used for scripts, PowerShell, notes, and keeping work organised outside the database itself.
• Slack and Microsoft Teams
  Communication across the company. Slack is where most day-to-day conversations happen; Teams is mainly used for incidents and larger coordination.
• Grafana
  Dashboards and alerts that give early warning when something starts to drift before it becomes a real problem.
• ServiceNow
  Handling requests, incidents, and change management in a way that’s auditable and predictable.
• Azure
  The cloud platform underneath much of the infrastructure we support.
• Microsoft Office
  Documentation, planning, and the unavoidable admin that comes with any engineering role.

I’ve been writing about SQL Server since my first DBA role over ten years ago and have published over 100 posts on peter-whyte.com, covering everything from day-to-day production issues to deeper technical topics. I continue to write more detailed, hands-on posts about SQL Server monitoring, automation, and DBA tooling, now collected in a new home at sqldba.blog, where the focus is on practical examples and real-world production systems.

---

Working From Home in Edinburgh

My home setup is simple. I work mainly from a 22″ curved monitor, with my laptop off to the side, and a mechanical keyboard I’ve been using for maybe ten years now (still love it). Two screens in total, enough space to work comfortably without turning the desk into a command centre.

There are no real distractions during the day. No background noise, no interruptions. That quiet is great for focus, but it also means self-motivation matters. No one is watching, and no one needs to.

To change the atmosphere, I’ll sometimes take my laptop and work from a local coffee shop for a few hours. A different space and a bit of background noise can be surprisingly good for focus, especially when you’ve been deep in technical work for days.

One of the underrated benefits of working from Edinburgh is how easy it is to reset. Within 30 minutes, I can be out on a local walk, climbing one of the nearby hills, or wandering through small wooded trails. Getting outside and moving makes a genuine difference, particularly in a role that’s mostly about thinking rather than typing.

I write about those walks, hikes, and the wider outdoors across Scotland in other posts too. It’s something I’ve always enjoyed sharing alongside the technical side of my work. I’m particularly drawn to long-distance trails; I’ve completed the full walk from Glasgow to Inverness over a ten-day period, and I’ve started documenting it with one post per day, beginning with West Highland Way – Day 1. The plan is to finish that series properly, capturing each day of the trail in its own post.

---

Parenting, School Runs, and Remote Work That Actually Works

School drop-off is at 8:45am. On the way back home, I often grab a coffee from Costa. By 9am, I’m online! Or maybe 915am if there’s a queue 🙂

It’s genuinely the best way to start the day. Breakfast together, walking my daughter to school, and then we both head off to our own busy days.

One of the biggest advantages is having control over when I do the work. If there’s a school event, a holiday coming up, or something family related on the horizon, I can plan around it by working more hours earlier in the week or picking things up later when it suits. There is flexibility, but it comes with responsibility. We work hard, and that trust is earned over time.

Taking time off is straightforward, and holidays are easy to plan when needed. The expectation is not rigid hours, it is delivering good work and being available when it matters.

In theory, I could work from anywhere in Europe. If I wanted to move to another country, that is a conversation I could have and a request I could put in. But I am based in Scotland. It is home, and it is where my kid is. Having a job that fits around that, rather than competing with it, makes a real difference.

Remote work does not remove the effort. It removes the unnecessary friction.

---

Staying Productive Without Burnout

I try to get my most focused work done earlier in the day, before the US comes online. Between 3pm and 5pm, things naturally get busier as more teams log on, which often shifts the day from deep work into coordination mode.

Sometimes, if I’m in the middle of a project or a piece of coding, I’ll get carried away and keep going into the evening. That’s usually on me. When you’re working on something proactive or creative, like improving monitoring or refining alerting, it’s easy to want to finish the thought while it’s still fresh. Those kinds of improvements are always a win, and they’re part of what makes the job satisfying.

That said, evening creep is real. As more people come online later in the day, messages pick up and Slack noise increases. Managing that is important. I’m deliberate about silencing notifications and setting boundaries, otherwise it becomes exhausting. Slack is a great tool, but heavy request traffic can drain your focus quickly if you let it.

I also make space for life outside work. I have gym classes on some midweek evenings, and I’ll step away even if things are busy, let people know I’ll be back later, then log on for an hour when I return. That balance matters. Some evenings I’ll keep my laptop nearby and stay visible until around 10.30pm, but that’s a choice, not an expectation.

On-call weeks change the rhythm slightly. Most alerts tend to land at weekends due to the follow-the-sun model, but it’s not unusual to be woken at 2am during the week either. If you were online late the night before, it’s not much fun, but it’s part of the responsibility that comes with the role.

When I need to reset during the day, I step away. A short walk, a quick house task, or just getting outside helps. I tend to treat that as a reward after finishing something meaningful. Protecting systems is the job, but protecting your own energy is just as important if you want to do it well over the long term.

---

Advice for Junior Engineers

If you’re early in your career, expect not to fully understand your job for a while. That’s normal. Most roles, especially in infrastructure and databases, take years to really click.

What matters more than anything early on is consistency. Show up every day, pay attention, and listen more than you speak. You learn far more from watching how experienced engineers think than from trying to prove what you already know.

One thing I believe strongly in is building things yourself. Install SQL Server at home. Configure it properly. Set up backups, replication, and Always On. Try things in Azure or AWS. Break it in safe ways and take the time to understand why it broke and how you would fix it in a real environment.

Spend time getting comfortable with SSMS. Learn the interface properly, use the shortcuts, and understand what the tools are actually doing under the hood. SQL fluency comes with time, but real system understanding only comes from hands on experience.

I continue to write practical walkthroughs and deeper technical posts on sqldba.blog, especially around building, breaking, and learning from real SQL Server environments. I definitely recommend you start blogging too!

---

What People Underestimate About SRE / DBA Work

If nothing critical is happening, it is often because the job is being done well.

Good monitoring, automation, performance tuning, and preventative work make systems look boring. That is the goal. When things are running smoothly, there are no alerts, no incidents, and nothing demanding immediate attention.

Automation is a big part of that. We automate things like monthly patching and repeatable operational tasks to save time and reduce risk. If automation saves you a day or two of engineering time each month, you rarely notice the “free” time. You simply move straight on to the next piece of work.

That is because there is always something to be improving. When things get quiet, the focus shifts to making systems better rather than waiting for them to fail. That might mean improving automation, reviewing server performance, consolidating databases, tracing and retiring unused systems, refining alerting, or looking at cost optimisation.

The irony is that the better you get at this kind of work, the quieter it becomes. Problems are avoided rather than reacted to, and that effort is mostly invisible.

That is why documenting your impact matters. Not as self promotion, but as a way of showing the value of the work that keeps everything running.

---

What I Wouldn’t Trade

There are two things I wouldn’t trade, without hesitation.

The first is the team.

I’ve worked with them for over four and a half years now. If you need help, someone answers. Every time. There’s a level of trust and reliability that only comes from working with people who genuinely know their craft and care about the outcome. The mentorship I’ve had from people in this team has had a huge impact on my career. Many of them have twenty plus years of experience in the field, and that depth shows in how calmly and methodically problems get solved.

Our manager is a great example of that. They hold a Microsoft Master certification, which is one of the hardest Microsoft certifications to achieve. It requires deep technical knowledge across multiple areas, rigorous exams, and practical assessments at a level very few people ever reach. Having that kind of experience and leadership around you raises the bar for everyone, whether you realise it or not.

The second thing is the autonomy.

There are no cameras, no performative presence, and very little noise for the sake of noise. Sometimes people do not see my face for a year, even interviews are knowledge first. You are judged on what you know, how you communicate, and how you contribute. That creates an environment where people focus on doing good work rather than proving they are busy.

As a company, we are encouraged to be courageous, to try things, to improve systems, and to keep getting better. That philosophy aligns closely with how I think about work and growth. I believe in continuous improvement over time. Slow and steady wins the race. I often think of it as a snowball effect, where you get better almost unconsciously because your knowledge and experience keep expanding into new territory.

That combination of trust, mentorship, and a genuine drive to improve is rare. It is also the reason I would not go back to an office based DBA role again.