The most common question we hear from prospective clients: "What does this actually look like day-to-day?" Fair question. The concept of a fractional DevOps team sounds great in theory, but the practical reality matters.
Here's what a real day looks like for one of our teams embedded in a Series B SaaS company with ~40 engineers. This client runs on GKE with 3 environments, uses GitLab CI, and we're allocated 40 hours/month (roughly 10 hours/week).
9:00 AM — Async standup
Our engineers are in the client's Slack workspace. Every morning, we post an async standup in the #devops channel:
- What we worked on yesterday
- What we're working on today
- Any blockers or decisions needed from their team
We join their live standup once a week (Tuesdays). The rest of the week, async keeps everyone aligned without eating into meeting time.
9:30 AM — Monitoring review
First thing every morning: check the dashboards. We have Grafana dashboards for cluster health, application performance, and cost metrics. Today, we notice CPU utilization on the API pods spiked to 85% overnight — unusual for off-peak hours. A quick kubectl top pods confirms it. One of the pods is in a crash loop. We check the logs, find an OOM kill, and bump the memory limit. The developer who owns the service gets a Slack message with what happened and a suggestion to look at the memory leak in their next sprint.
10:00 AM — Sprint work
The bulk of our hours go to planned sprint work. This week, we're working on:
- Monday–Tuesday: Setting up a new staging environment for a feature team that's building a v2 API
- Wednesday: Automating database backup verification (restoring backups to a test instance and running a health check)
- Thursday–Friday: Updating Terraform modules for the new GKE node pool their ML team needs
Today is Tuesday, so we're finishing the staging environment. The new namespace, RBAC roles, database, and CI pipeline are all defined in Terraform and committed via PR. A developer on their team reviews and approves it — they own the merge.
1:15 PM — Incident response
PagerDuty alert: certificate expiring in 7 days on a secondary domain. Not an emergency, but it needs attention. We check cert-manager, find the Let's Encrypt renewal is failing because a DNS record was changed last week. We fix the DNS record, force a renewal, verify the new certificate, and add a monitoring check for cert expiry < 14 days across all domains. Total time: 25 minutes. Slack message to the team with what happened and the new monitoring rule.
3:00 PM — Developer support
A developer asks in #devops: "How do I add a new environment variable to the API in staging?" Instead of doing it for them, we point them to the Helm values file and the PR template. They submit the PR, we review it, they merge. They now know how to do it themselves next time.
This is intentional. Our goal isn't to create dependency — it's to build self-service capability. We create the platforms, templates, and documentation; the developers use them.
4:00 PM — Documentation
The last 30 minutes of the day: update runbooks, architecture diagrams, and the decision log. Today we add the OOM investigation and the cert fix to the incident log, and update the staging environment setup guide with the new namespace.
What makes this work
- Two engineers, always. Our primary engineer is on this account Monday–Thursday. Our secondary checks monitoring daily and covers Fridays and vacations. The client never has zero coverage.
- Slack-first communication. We're in their workspace, available during their business hours. Response time for non-urgent questions: under 2 hours. For urgent alerts: under 15 minutes.
- Shared backlog. Our work items live in their project management tool (Linear, Jira, etc). Their VP Engineering sets priorities. We execute.
- Monthly review. A 30-minute call at the end of each month: what we did, what's coming, any adjustments needed to the hours or focus areas.
It feels like having a DevOps team. Because you do — you just don't have to hire, manage, or worry about retention.