The specific signals an experienced site reliability engineer hiring panel grades on during the eight-second scan.

• Summary names SLO ownership, not 'reliability'

  'Owns the 99.95% SLO on the payments service' beats 'SRE focused on reliability.' SLO ownership is the differentiator.

• Error-budget mechanics named

  Burn-rate alerts, error-budget freeze, multi-window multi-burn-rate. Vocabulary panels use to grade depth.

• Incident command experience

  Count of incidents as IC, MTTM improvement, postmortem authorship. SRE roles past mid-level expect this.

• Toil reduction quantified

  Hours saved per quarter, alerts deleted, manual interventions automated. Toil work is the SRE bread-and-butter.

• Observability stack named

  Prometheus, Grafana, OpenTelemetry, Datadog, Honeycomb. Exact products parse better than 'observability tools.'

• One non-trivial automation shipped

  Auto-remediation runbook, capacity planning automation, chaos-engineering rig. Validates the SRE claim more than any bullet.

1. 1

   Open with the SLO and the service

   A staff SRE summary names the SLO: 'Owns the 99.99% availability SLO on the global checkout service.' A senior summary names the same: 'SRE at a payments company; owns the 99.95% SLO on the bank-rails service ($1.2B annualised volume).' A mid-level summary names the SLO and the system class: 'SRE on the platform team; owns SLOs across 8 internal-services pages on the 99.9% tier.'

   Lead with the SLO. The number signals what class of system the candidate has been graded on quarterly. 99.9% is one tier; 99.95% is another; 99.99% is another. A 2026 SRE hiring panel reads these tiers as different jobs.

2. 2

   Quantify with MTTM / MTTI / MTTR

   Mean time to mitigation (MTTM), mean time to investigation (MTTI), mean time to recovery (MTTR), incident-command count, postmortem count, alert volume, on-call eng-hours. These are SRE units of measure.

   The specific numbers to favor: • MTTM before/after with the timeframe. • MTTI improvement after observability work. • Incident-command count by severity. • Alert volume reduction. • On-call eng-hours per rotation. • Toil-hours saved per quarter. • Postmortem count with corrective-action completion rate.

3. 3

   Name the observability + alerting stack

   Prometheus, Grafana, Loki, Tempo, Thanos for the open-source side. Datadog, Honeycomb, Sentry, New Relic for SaaS. Name the products. SRE JDs match against products directly.

   Name the alerting choice: multi-window multi-burn-rate, threshold-based, anomaly-detection-based. Name your on-call rotation system: PagerDuty, OpsGenie. Name your incident-command tool: Slack workflows, FireHydrant, Rootly.

4. 4

   Name the toil-reduction work

   Toil reduction is the SRE bread-and-butter. The pattern that works: • 'Automated the bank-rails on-call toil work via a self-healing runbook.' • 'Built the capacity-planning automation; quarterly forecast accuracy went from ±18% to ±4%.' • 'Deleted 38% of alerts after the SLO-based alerting migration; no missed incidents.' • 'Built the chaos-engineering rig (Gremlin + GameDay framework); ran 14 GameDays through the year.'

   Quantify in eng-hours where possible — toil work is graded on engineer-hours saved per quarter.

5. 5

   Close with postmortem culture or OSS

   The high-signal closing item is either postmortem-culture leadership or a merged contribution to a recognized observability library.

   Postmortem signal: • Count of postmortems authored, blameless-template adoption, corrective-action completion rate. • Postmortem-review meeting cadence and the outcomes it produced.

   OSS signal: • Merged PRs to OpenTelemetry, Prometheus, Thanos, Tempo, Loki, Vector, Pyroscope. • SREcon talk, CloudNative talk, KubeCon talk. • A blog post on postmortem mechanics that gained traction.

Each follows the [verb] [object] [number] structure hiring managers grade against. Copy them as a starting point, swap in your own numbers, and read the annotation to understand why each one works.

• Alerting

  Restructured the alerting on the bank-rails service from threshold-based to multi-window multi-burn-rate SLO alerts; alert volume fell 76% with no missed SLO-breaching incidents over 9 months.

  Why it works: Names the alerting pattern (a recognizable Google SRE Book technique), the volume delta, and the no-regressions outcome over a sustained window.

• Incident command

  Led IC on 11 incidents through 2024 (3 Sev-1, 8 Sev-2); authored the team's blameless-postmortem template now adopted across 4 service teams. MTTM on bank-rails incidents fell from 47 to 14 minutes.

  Why it works: IC count, severity breakdown, postmortem-template adoption, MTTM outcome. The combo is the SRE senior signature.

• Toil reduction

  Automated the bank-rails on-call toil via a self-healing runbook (Terraform + Lambda + PagerDuty Rundeck); on-call eng-hours per rotation fell from 14 to 3 across 4 quarters.

  Why it works: Names the toil-automation tooling, the on-call eng-hour outcome, and the longitudinal window.

• Observability

  Migrated 12 services from StatsD + ELK to OpenTelemetry + Tempo + Grafana; cut MTTI on cross-service traces from 22 minutes to under 4 minutes.

  Why it works: Names the migration, service count, and MTTI outcome. MTTI is SRE-specific vocabulary used correctly.

• Capacity planning

  Built the capacity-planning automation (Python + Prometheus historic data + statistical forecast); quarterly forecast accuracy went from ±18% to ±4% across the production-services fleet.

  Why it works: Names the tool stack, the forecast metric, and the accuracy improvement. Capacity planning is SRE-specific and the bullet proves it.

• Chaos engineering

  Owned the GameDay program through 2024 — ran 14 chaos-engineering exercises across 3 service teams; surfaced 22 latent reliability bugs (8 Sev-1 candidates if surfaced in prod).

  Why it works: Names GameDay count, the cross-team scope, and the bug count with severity calibration. Chaos-engineering work is SRE-specific senior signal.

• Mentorship

  Wrote the team's first on-call ramp curriculum; new SRE primary-rotation ramp dropped from 8 weeks to 3 weeks across the last 4 hires.

  Why it works: Names the curriculum work, the ramp metric, and the cohort it applies to. Ramp time is a senior-track operational outcome.

• Alert hygiene

  Reduced PagerDuty alert volume by 84% (from ~120 to ~19 per week) by deleting low-signal alerts, migrating threshold-based alerts to SLO-based, and folding 6 redundant alerts into a single SLO.

  Why it works: Three-part intervention with absolute and relative numbers. Alert-hygiene work is SRE-specific and the bullet proves it.

• Open Source

  Two merged PRs to open-telemetry/opentelemetry-collector — one closed a metric-cardinality leak under high-volume scrape configs; one extended OTLP exporter for self-monitoring.

  Why it works: Named library (OpenTelemetry Collector), two PRs, and one technical description that signals SRE depth (cardinality leaks). Hiring panels recognize the depth.

• Postmortems

  Authored 11 blameless postmortems through 2024; 38 corrective actions shipped within the 60-day window (89% completion rate).

  Why it works: Names postmortem count, corrective-action count, completion rate, and timeframe. Postmortems with corrective-action follow-through are the SRE-specific senior signal.

• Platform

  Shipped a Prometheus + Thanos federation rebuild across 4 production clusters; query latency on the global dashboards p95 fell from 8.2s to 480ms.

  Why it works: Names the tool stack, the cluster scope, and a query-latency outcome. Federation work is hard to demonstrate; the latency number proves the rebuild landed.

• Tooling

  Built the dashboard library for the platform team (Grafana JSON + Jsonnet); 38 dashboards deployed across 12 services. Each dashboard auto-includes SLI + SLO panels and budget-burn alerts.

  Why it works: Names the tooling, the dashboard count, and the SLI/SLO integration. Internal-tooling work is SRE-specific and the bullet quantifies it.

Same intent, two phrasings. Read why the right column lands on the keep-pile and the wrong column doesn't.

Patterns our writers see most often when reviewing site reliability engineer resumes — each one disqualifies candidates faster than weak experience does.

• Mistake

  Opening with 'passionate about reliability.'

  Fix

  Lead with the SLO. 'Owns the 99.95% SLO on the bank-rails service.' The number is the senior signal.

• Mistake

  Generic 'observability' mentions without product names.

  Fix

  Name Prometheus, Grafana, OpenTelemetry, Tempo, Loki, Datadog, Honeycomb by exact product.

• Mistake

  No incident-command experience surfaced.

  Fix

  If you've led IC on incidents, surface count and severity. Past mid-level, SRE roles expect IC experience.

• Mistake

  Vague 'reduced toil' claims.

  Fix

  Quantify in eng-hours per quarter or per rotation. Toil is graded on engineer time saved.

• Mistake

  Listing every cloud and tool you've touched.

  Fix

  Group by category, weight toward depth. The Goldilocks band is 15-25 items.

• Mistake

  Using devops vocabulary in an SRE resume.

  Fix

  SRE-specific tokens (SLO, error budget, multi-window burn-rate, blameless postmortem) parse better than generic devops tokens for SRE roles.

• Mistake

  Two-page resume with fewer than 8 years experience.

  Fix

  One page. SRE hiring panels move fast.

• Mistake

  Hidden white-text keyword stuffing.

  Fix

  Don't. Modern ATS flags it; sophisticated companies disqualify.

Strong verbs lead strong bullets. Replace generic openers (worked on, helped with, was responsible for) with the specific verb that matches what you actually did.

ATS pipelines weight your Skills section as a structured list. Include 15-25 of the items below if they match your experience — not soft skills.