30-60-90 day plan for site reliability engineers
On this page
- How is an SRE's first 90 days different from a DevOps engineer's?
- What do SLOs, error budgets and toil mean for the first 90 days?
- What does the 30-60-90 day plan look like?
- Which numbers should a new SRE baseline?
- Which rules apply when an outage is also a reportable incident?
- What does "on track" look like at day 30, 60 and 90?
- A filled example
- How should the hiring manager use this plan in the final interview?
- What should the manager ask at the check-ins?
- What the manager owes a new SRE
- Common mistakes
- Adapting the plan
- Questions people ask
A 30-60-90 day plan for a new site reliability engineer should learn the services, their SLOs and error budgets, the on-call load and the recent postmortems in the first 30 days; join on-call in stages and take ownership of one service's SLO and alerts in days 31-60; and by day 90 deliver one reliability improvement measured against the error budget, with a measured cut in toil or pager noise. Google's site reliability engineering book, free to read at sre.google, defines an error budget as a rate at which SLOs can be missed and caps operational work at 50 percent of an SRE's time. As of November 2026, DORA's delivery metrics page lists five measures, including deployment rework rate, that tie releases to reliability.
This page is for the SRE manager, engineering manager or platform lead hiring a site reliability engineer, production engineer or reliability engineer into an existing team. Pipelines, build times and infrastructure code are in the 30-60-90 day plan for DevOps engineers; servers, identity, backups and patching in the 30-60-90 day plan for systems administrators; routing, firewalls and circuits in the 30-60-90 day plan for network engineers.
How is an SRE's first 90 days different from a DevOps engineer's?
| Area | Site reliability engineer | DevOps engineer |
|---|---|---|
| Main question | Is the service reliable enough for its users, and how do we know? | Can engineers ship changes quickly and safely? |
| Core records | SLOs, error budgets, alert rules, runbooks, postmortems, capacity plans | Pipelines, infrastructure code, build and deploy history |
| On-call | Central: incident response, escalation and the rotation's health | Often shared, focused on the delivery platform |
| Day-90 result | A reliability improvement shown against an SLO, and less toil | A faster or safer delivery path, shown in build and deploy data |
Many companies use the two titles for the same seat. If so, agree in week one which of the two results the day-90 review will look for.
What do SLOs, error budgets and toil mean for the first 90 days?
The terms come from Google's SRE book and its companion, the SRE workbook. The table quotes or summarizes them; the targets any one company uses are its own.
| Term | What the source says | What it means for the plan |
|---|---|---|
| SLI and SLO | An SLI is "a carefully defined quantitative measure of some aspect of the level of service"; an SLO is a target value or range for a service level measured by an SLI; the chapter advises having as few SLOs as possible | Learn each service's SLIs and SLOs first, and check they measure what users feel (Service Level Objectives) |
| Error budget | "A rate at which the SLOs can be missed," tracked daily or weekly | The new SRE should know each service's remaining budget by day 30 |
| Error budget policy | Google's example halts all changes and releases other than P0 issues or security fixes when a service exceeds its budget for the preceding four weeks, and requires a postmortem when one incident uses more than 20 percent of the four-week budget | Find out whether the team has a policy, and whether anyone follows it (Example error budget policy) |
| Toil | Work tied to running a production service that tends to be "manual, repetitive, automatable, tactical, devoid of enduring value," and grows linearly with the service; the goal is to keep it below 50 percent of each SRE's time | Measure the team's toil in month one; cut one source by day 90 (Eliminating Toil) |
| On-call load | No more than 25 percent of an SRE's time on call; a maximum of two incidents per 12-hour shift; at least eight engineers for a single-site rotation, or six per site for two sites | Compare the real pager load with these figures before joining primary on-call (Being On-Call) |
| Postmortems | Example triggers include user-visible downtime beyond a threshold, any data loss, on-call intervention such as a rollback, resolution time above a threshold and a monitoring failure; postmortems focus on contributing causes "without indicting any individual or team" | Read the last postmortems in week one; lead one by day 90 (Postmortem Culture) |
What does the 30-60-90 day plan look like?
30-60-90 day plan — [Name], Site Reliability Engineer, [team]
Reports to: [SRE manager / engineering manager] Start date: [date]
Services supported: [ ] Rotation: [N engineers, follow-the-sun?]
Tools: [monitoring, paging, incident tracker, dashboards, runbooks,
infrastructure code, deploy system]
DAYS 1-30 — Learn the services and the signals
Goals:
- Read each service's SLOs, current error budget and alert rules
- Read the last [6] postmortems and check whether their actions
were completed
- Shadow a full on-call rotation; note every page, whether it was
actionable and whether the runbook was right
- Map dependencies for the top [3] services, including third
parties and shared data stores
- Estimate the team's toil: what repeats every week, and how long
it takes
- Merge [3-5] small reviewed changes (an alert fix, a runbook,
a dashboard)
Deliverables by day 30:
- Reliability baseline: SLO attainment, budget burn, pages per
shift, time to mitigate, toil estimate
- List of alerts that page without needing action
DAYS 31-60 — Join on-call and own an SLO
Goals:
- Secondary on-call for one rotation, then primary with a backup
- Own [service]'s SLO, alerts and dashboard: check the SLI measures
what users feel; tune or remove noisy alerts
- Write or fix the runbooks for the [5] most frequent pages
- Propose one reliability improvement with its expected effect on
the error budget
Deliverables by day 60:
- Alert changes for [service], reviewed by a senior SRE
- One-page proposal for the day-90 improvement
DAYS 61-90 — Improve reliability and cut toil
Goals:
- Ship the improvement (example: a retry and timeout fix, a
capacity change, an automated rollback) and measure it
- Automate or remove one source of toil from the day-30 estimate
- Lead one postmortem or a game day
- Review a production readiness check for a new or changed service
Deliverables by day 90:
- The improvement, measured against the error budget
- Toil reduced, with before and after hours
Check-ins: weekly with [manager]; reviews at day 30, 60 and 90.Numbers in brackets are examples; adjust them to the rotation and the number of services.
Which numbers should a new SRE baseline?
The measures are examples. Build the baseline from the monitoring, paging and incident systems, note where the data is unreliable, and set targets only after the day-30 review. DORA's software delivery performance metrics add the release side: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate, which DORA describes as the share of deployments that are unplanned and triggered by a production incident.
| Measure (examples only) | What it shows |
|---|---|
| SLO attainment and error budget remaining, by service | Which services are closest to breaking their promise to users |
| Pages per on-call shift, and the share that needed action | Alert quality and the rotation's health |
| Time to mitigate incidents, by severity | How quickly users get service back |
| Postmortem actions completed by their due date | Whether the team learns from incidents |
| Toil hours per week, estimated by the team | How much time is left for engineering |
| Change fail rate and deployment rework rate | How often releases cause the incidents on-call handles |
| Capacity headroom on the most constrained resource | The next outage that traffic growth will cause |
Which rules apply when an outage is also a reportable incident?
Most SRE work is governed by internal policy, but some outages are also regulated events. As of November 2026, not legal advice:
- EU financial entities: Regulation (EU) 2022/2554, the Digital Operational Resilience Act (not to be confused with the DORA delivery metrics), has applied since January 17, 2025. It requires financial entities to report major ICT-related incidents to their competent authority, with an initial notification, intermediate reports and a final report once the root cause analysis is complete, and requires entities identified for it to carry out threat-led penetration testing at least every three years (Regulation (EU) 2022/2554). An SRE at such a firm needs to know who decides an incident is "major" and how fast that decision must reach them.
- Incident response practice: NIST SP 800-61 Rev. 3 (April 2025) replaced the 2012 Rev. 2 and places incident response inside the NIST Cybersecurity Framework 2.0 (NIST SP 800-61 Rev. 3). It is the reference when the security team and SRE share an incident process.
- Public companies: material cybersecurity incidents carry disclosure duties that the security and legal teams own; the 30-60-90 day plan for CISOs covers them. The SRE's part is a timeline good enough for others to rely on.
What does "on track" look like at day 30, 60 and 90?
| Checkpoint | On track | Worth a direct conversation |
|---|---|---|
| Day 30 | Baseline written with sources; noisy alerts listed; on-call shadow done; can name the service closest to its budget | No written baseline; changes made directly in production; postmortems not read |
| Day 60 | Secondary and first primary shifts handled with sensible escalations; owned SLO checked against user experience; noisy alerts tuned | Avoiding pages; alerts silenced without agreement; SLO accepted without checking what it measures |
| Day 90 | Improvement measured against the error budget; one toil source removed; a postmortem led well | Improvement described as "more stable" with no measure; toil unchanged |
A filled example
Site reliability engineer: Leila Haddad (invented), joining a six-person SRE team at a payments software company, supporting the checkout and ledger services. All details are examples.
Day 30: Her baseline showed the checkout service had spent most of its four-week error budget, mainly on timeouts to a third-party fraud check. Many pages during her shadow week needed no action. Two postmortems from earlier in the year had open action items for retries that were never built.
Day 60: She took ownership of the checkout SLO and found its SLI counted only server errors, not timeouts users saw. The team changed the SLI and removed alerts that paged for conditions that resolved on their own. She proposed a timeout and fallback for the fraud check.
Day 90: The fallback shipped behind a flag, and timeout-related budget burn dropped over the next weeks. A weekly manual certificate check was replaced with automated expiry alerts, saving the rotation several hours a month. She led the postmortem for a ledger delay and closed the old retry actions.
How should the hiring manager use this plan in the final interview?
Give every finalist the same brief: the services, a dashboard screenshot with SLOs and budget burn, a recent anonymized postmortem and the rotation size. Score the plans with the rubric in how to evaluate a 30-60-90 day plan in an interview. A strong SRE plan checks that SLOs measure what users feel, stages on-call, and measures toil before automating it. Questions that test it:
- "A service has burned its error budget but the product team wants to ship a launch this week. What do you do?"
- "The rotation gets paged many times a night and most pages resolve on their own. Where do you start?"
- "Our SLO is 99.9 percent and we meet it, but customers complain. What might be wrong?"
- "Walk me through the first fifteen minutes of a major incident you led."
Earlier in the process, the site reliability engineer screening questions check SLO, incident and on-call experience, and the DevOps engineer screening questions cover infrastructure basics that also apply to SRE candidates.
What should the manager ask at the check-ins?
- Day 30: Which service worries you most, and what is its budget telling us? Which alerts would you delete tomorrow?
- Day 60: How did on-call go, and what was wrong in the runbooks? Does the SLO you own measure what users feel?
- Day 90: What did the improvement do to the budget? How many hours of toil did you take out, and what is next?
What the manager owes a new SRE
- Read access to production telemetry, dashboards and the incident history on day one, and a written path to change and on-call rights.
- An onboarding buddy for the shadow rotation and the first primary shifts.
- An honest account of which SLOs are trusted, which policies are followed and which postmortem actions never happened.
- Protection for project time: if toil and tickets fill the week, the day-90 improvement will not happen.
Common mistakes
- Primary on-call in week one. It tests the runbooks, not the engineer, and burns trust on both sides.
- Accepting SLOs as written. An SLI that misses what users feel makes a green dashboard meaningless.
- Automating before measuring toil. The biggest time sink is often not the most visible one.
- Silencing alerts without agreement. Tune or delete them through review, with the owner's sign-off.
- Blame in postmortems. People stop reporting what they saw, and the real causes stay hidden.
Adapting the plan
- Embedded SREs on a product team: weight month two toward production readiness reviews and the team's release process, working with the engineering manager.
- First SRE at a company: there may be no SLOs, policies or rotation; the day-30 deliverable becomes draft SLOs for the top services and a proposed on-call design, and the 30-60-90 day plan for engineering managers shows what the manager will be balancing.
- Regulated financial services: add the incident classification and reporting path to month one and attend one resilience test or tabletop before day 90.
- Platform and infrastructure SREs: the users are internal teams, so SLOs describe the platform they rely on; borrow the delivery baseline from the DevOps plan.
Questions people ask
What should a new site reliability engineer do in the first 30 days?
Learn the services the team supports and how users experience them: read each service's SLOs and current error budget, the last several postmortems and the runbooks, shadow a full on-call rotation, map the main dependencies, and measure the pager load and how much of the team's week goes to toil. By day 30 the new SRE should be able to say which service is closest to running out of error budget and why.
What is an error budget?
Google's SRE book describes an error budget as a rate at which a service's SLOs can be missed, used instead of demanding 100 percent reliability. An error budget policy says what happens when the budget is spent: Google's example policy halts changes and releases other than P0 issues or security fixes until the service is back within its SLO, and requires a postmortem when a single incident consumes more than 20 percent of the four-week budget.
How much on-call is reasonable for an SRE?
Google's SRE book caps operational work at 50 percent of an SRE's time and says no more than 25 percent can be spent on call, and it works out a maximum of two incidents per 12-hour on-call shift. It also says a single-site team needs at least eight engineers for on-call and a dual-site team at least six per site. Teams set their own limits, but those figures are a useful check on whether a rotation is sustainable.
How is a site reliability engineer different from a DevOps engineer?
The titles overlap, and many companies use them interchangeably. Where they differ, a DevOps engineer's plan centers on the delivery system, such as pipelines, infrastructure code and build times, while an SRE's plan centers on the reliability of running services: SLOs, error budgets, alerting, on-call, incident response, postmortems and capacity. An SRE's day-90 result is usually a reliability improvement measured against an SLO.