Platform engineering with an observability edge.
I build the automation, infrastructure-as-code and operating capabilities that let service teams ship, observe and own reliable systems across on-prem and GCP.
Miles Whittaker · Platform engineer · UK → Germany
Platforms that
teams can own.
I build the automation, operating paths and self-service capabilities that help teams run reliable systems — shaped by enterprise-scale observability and incident-management work.
50+ teams supported
3,000+ services in the estate
800+ PagerDuty users
MW / 01
About / 01
Reliability is a team
sport.
I’m Miles, a platform engineer at bet365 with a foundation in operations and infrastructure. Since moving into observability in 2024, I’ve led monitoring and incident-management transformation at enterprise scale — experience that now informs how I build platforms.
My work spans on-prem and GCP: replacing legacy monitoring, onboarding bespoke systems, and creating the automation and delivery paths that keep configuration consistent. I focus on more than tooling — clear ownership, practical training and self-service are what make platform change last.
I work across engineering teams and senior stakeholders to move response closer to the people who own each service: less central triage, less platform toil, and a clearer path from signal to action.
Experience / 02
The useful
30 seconds.
Platform engineer building reliable, self-service foundations across hybrid environments — with enterprise-scale observability and incident-management transformation as a differentiating edge.
Credentials that travel.
- CKACertified Kubernetes Administrator · Linux Foundation · Aug 2026—Aug 2028
- GCP ACEAssociate Cloud Engineer · Google · Jul 2024—Jul 2027
- AWS SAAAWS Solutions Architect—Associate · previously held · expired Oct 2025
One story, ready to send.
Primarily targeting Platform Engineering roles in Germany, with SRE and Forward Deployed Engineer roles also a strong fit where hands-on delivery, customer context and adoption matter. Berlin is a primary target.
Request the CV ↗Selected experience
Problem → intervention → result.
Jan 2024—PresentObservability Engineer · bet365
Leading observability and incident-management transformation across on-prem and GCP: tens of thousands of hosts, 50+ teams, 800+ PagerDuty users and 3,000+ services.
Apr 2023—Jan 2024IT Operations Engineer · bet365
Owned monitoring, incident triage, service continuity and change operations for mission-critical systems.
Technical stack
Terraform · Ansible · GCP · GitLab CI/CD · New Relic · PagerDuty · Telegraf · Grafana · Pyroscope · AWS · Kubernetes · Docker · Linux
DE
Open to work
Berlin, Germany + other locations · hybrid or remote.
Based in the United Kingdom and actively exploring Germany-based Platform Engineering opportunities, alongside selected SRE and Forward Deployed Engineer roles. English is the authoritative site language for now.
Selected platform work / 03
Proof, not promises.
Platform outcomes, delivered through observability: modernising monitoring at scale, making delivery repeatable, and shifting incident response to service owners.
From Nimsoft to New Relic
Migrated observability across tens of thousands of hosts and hundreds of microservices. Automated rollout with Ansible and built bespoke integrations in Bash, PowerShell and Flex/cURL for systems standard agents could not cover.
Terraform and GitLab brought monitoring configuration under version control, making it repeatable and team-owned.
Off-host checks with Telegraf
Replaced legacy Nagios ICMP checks with a highly available Telegraf-based service supporting hundreds of checks. Standardised rollout with Ansible to reduce configuration drift and simplify onboarding.
Built a GitOps pipeline to lint, test with telegraf --test, and deploy using Terraform, Ansible and GCP Cloud Deploy.
PagerDuty to service ownership
Led adoption across 50+ teams, 800+ users and 3,000+ services. Developed Terraform modules and Events API integrations, with service provisioning automated from CMDB and GKE discovery.
Routed alerts directly to service owners, reducing reliance on central triage. Improved alert quality with standards, grouping, hygiene and auto-pausing.
Interactive proof / 04
Platform Atlas.
A deliberately generic, sanitised model of how platform changes and signals connect. Built as a teaching and onboarding aid; it does not depict my employer’s architecture or live systems.
Sanitised demo dataDrag-free by design · click a flow
Evidence lab / 05
One release.
Three signals.
A small, public-safe fixture showing how the same deployment can be investigated through profiles, traces and a change timeline.
Continuous profiling / Go
Where did the CPU move?
baseliner2026.09.12
http.Server100%
serveHTTP61%
json.Marshal22%
encodeValue9%
candidater2026.09.13
http.Server100%
serveHTTP72%
template.Execute31%
escapeString14%
previous deploycurrent deploysample: 60 s CPU profile
OpenTelemetry / Tempo
Which span explains the wait?
GET /checkout
184 ms
auth middleware
18 ms
catalog service
74 ms
postgres query
112 ms
render response
21 ms
0 ms50100150200 ms
span durationinvestigate firsttrace id: 7f3a…c91e
Release evidence / Git
What changed between runs?
r2026.09.12 baseline
Profile capturedsteady-state traffic · 60 s sampler2026.09.13 candidate
Template path changedprofile diff → trace check → promote01build02profile03trace04decision
candidate releasecorrelation is a lead, not prooffixture data only
All evidence here is synthetic and illustrative — not taken from a live service or employer telemetry. This demo shows an investigation workflow, not a production incident.
How I work / 06
Clarity is a feature.
The most useful systems are not just resilient. They explain themselves when the pressure is on.
Design for the handover.
Good work survives the person who made it. Interfaces, runbooks and architecture should leave the next decision easier than the last.
Make evidence cheap.
Observability is not a wall of charts. It is the shortest path from “something changed” to “we know why”.
Keep the edges honest.
Public surfaces get the polish. Private systems get the boundaries. A demo should be impressive without pretending to be live.
Ship the smallest proof.
Start with a useful, measurable slice. Let the shape of the real problem earn the next layer of complexity.
Open channel / 07
Have a system
worth making clearer?
For platform work, reliability engineering or a Germany-based opportunity, I’d like to hear what you’re building.
Start a conversationhello@alias.whitt.ukManchester · UK → Germany