Example Achievement Log for a Site Reliability Engineer

This Site Reliability Engineer tracked incidents, deployments, and system changes across a year marked by infrastructure scaling and a major incident that taught hard lessons. The entries show both wins and the messy work of keeping systems running under pressure.

A year in the life of a Site Reliability Engineer's log

Feb - achievement: Reduced alert noise on prod-us-east-1 by tuning thresholds on the memory pressure rule. False positives dropped from 47 per week to 8. Team stopped dismissing pages out of habit.
Feb - task: Onboarded three new Operators onto the pager rotation. Built runbooks for their first week and shadowed their initial escalations. One week in, Jamie caught an unclean shutdown without prompting.
Apr - achievement: Automated the cert renewal pipeline for our 34 internal services using cert-manager on EKS. Manual renewal work dropped to near zero. Cut remediation time for expired certs from 2 hours to 5 minutes.
Jun - task: Spent three weeks investigating why our Kafka cluster was dropping batches under load. Root cause was GC pause tuning in the JVM config, not a network issue. Turned out I was wrong twice before landing on the answer.
Jul - feedback: Marco said in standup: 'You kept us from rolling back during the database failover. Your troubleshooting call saved the launch.' He asked me to document the steps for the wiki.
Aug - achievement: Led postmortem on the 4-hour outage caused by a config drift in our load balancer. Identified that we had no drift detection. Built a weekly scan using Terraform state. It caught 6 config skews in the first month.
Sep - task: Took point on the migration of batch jobs from EC2 to Spot instances across three regions. Learned that our retry logic had a bug that only showed up under Spot interruption. Fixed the bug but had to roll out the new instance type slower than planned.
Oct - achievement: Rewrote the deployment rollback procedure. Old version relied on manual kubectl commands and prayer. New version is automated, tests the rollback path in staging first, and rolls back automatically if metrics breach thresholds.
Oct - feedback: Sarah told me during our 1-1: 'The rollback automation gave us confidence to ship faster. We've done 23 deployments in the last two weeks without any pager alerts.' Said it changed how the team thinks about risk.
Nov - task: Became primary on-call for the data pipeline services. First week had 12 pages, only one was actually critical. The rest were noise from old checks we'd inherited. Built a cleanup checklist for the next rotation.
Dec - achievement: Documented our SLO targets for all four service tiers and linked them to alert thresholds. Previously we had vague uptime goals. Now we measure them in Prometheus and escalate based on burn rate. Framework is live for Q1.

What makes a strong entry

What most people write: Improved alert tuning and reduced noise on the production cluster.

What went in the log: Reduced alert noise on prod-us-east-1 by tuning thresholds on the memory pressure rule. False positives dropped from 47 per week to 8. Team stopped dismissing pages out of habit.

Specific cluster, named rule, before-and-after numbers, and the human outcome (the team stopped ignoring alerts). This proves you know what noise costs and that you measured the fix.

What most people write: Led a postmortem and implemented drift detection.

What went in the log: Led postmortem on the 4-hour outage caused by a config drift in our load balancer. Identified that we had no drift detection. Built a weekly scan using Terraform state. It caught 6 config skews in the first month.

Named the tool (Terraform), the failure mode, the scan frequency, and the outcome (6 skews caught). A vague postmortem entry is useless; the specifics show you understood the system and solved the real problem.

How this becomes your review in November

I spent this year reducing toil and building systems that let our team ship with confidence. Early on I tuned alerts so the team would stop ignoring pages, and by October I had automated the rollback procedure so deployments became safer instead of scarier. The work on postmortems showed me gaps we didn't know we had: we had no drift detection until the 4-hour outage taught us the cost, and no SLO targets until December. I learned in the Kafka investigation that being wrong twice is part of getting to the right answer, and the team told me that automation like cert renewal and rollback detection changed how fast they're willing to ship.

Starting your own log

Don't try to reconstruct a year you have already had. Start from today, one line whenever something happens, and let it build. The Perform Review Achievement Log does this for you and can capture wins straight from Slack, and how to start an achievement log covers the wider playbook.

Example Logs for Related Roles

Ready to start your own? Start your Achievement Log free, see how the Perform Review Achievement Log works, or browse performance review phrases for Site Reliability Engineer.