Build a service that can fail, then fix it
Take a small service you've built. Then:
- Add metrics with Prometheus and a dashboard on Grafana Cloud's free plan.
- Set two alerts, for errors and slowness.
- Break it on purpose and fix it, timing yourself.
- Write a runbook for that failure and a one-page blameless incident note with a timeline.
The free Google SRE books are worth reading alongside.
Backend experience that maps to reliability work
| You already do | What it becomes |
|---|---|
| Fixed production bugs | Lead incident response with a timeline |
| Read logs | Build dashboards and alerts that catch problems early |
| Wrote deployment scripts | Automate recovery steps |
| Wrote post-release fixes | Write blameless post-incident notes |
The new parts are thinking in service-level objectives (SLOs: targets like '99.5% of requests succeed'), writing runbooks (step-by-step fix guides), and working on rotations.
Are you the calm one during outages?
(Takes about a minute; answers stay on your device.)
- Have you been called when production broke? (yes / no)
- Have you read logs to find a root cause? (yes / no)
- Have you set up an alert or dashboard? (yes / no)
- Do you stay calm when things are on fire? (yes / no)
- Could you work some on-call or shift hours? (yes / no)
Four or five yeses: this bridge is short for you. Two or three: still reachable. Fewer: start with the backend developer role page and come back.
Incident Timeline
A pretend incident unfolds minute by minute. Put each moment where it belongs.
Incident Timeline
SRE salaries: we haven't checked
We haven't verified pay data for sre / production support roles. Rates differ by city, company and contract type.
Your realistic 90 days
You have probably been paged, or sat next to someone who was. SRE and production support turn that calm into the main job: watching a service, fixing it fast and writing down what happened. The plan uses one small service you break on purpose.
Assumes 2–3 hours a day alongside job applications, a laptop and a phone, and free plans only. Every step has a smaller version and a way to pause. Use them. It runs in three blocks of 30 days, each ending with a signal that you're on track. A signal is not a promise of a job or income.
The two worries we hear most about this move
Will I be stuck on night shifts? Some support roles have rotations; some SRE teams follow the sun across regions. Ask how on-call works and how often in the first interview. Isn't production support a step down? It can feel that way, but incident and monitoring skills are what SRE teams hire for. Treat a support role as a way in if you keep building automation alongside.
Other worries, such as age, a career gap, no degree, English, family pressure and savings, are covered on the route page and the role page.
Your first 7 days
| Day | Task | Done when |
|---|---|---|
| 1 | List 3 production incidents you handled and what caused them | 3 stories |
| 2 | Read the first chapters of a free Google SRE book | Notes |
| 3 | Add Prometheus metrics to a small service | Metrics visible |
| 4 | Build a Grafana Cloud dashboard on the free plan | Dashboard live |
| 5 | Set an error alert and trigger it on purpose | Alert fired |
| 6 | Write a runbook for that failure | Runbook done |
| 7 | Save 10 SRE or production support postings | 10 links |
Days 1–30: A monitored service
| Step | Time | Done when | Smaller version | If you need to pause |
|---|---|---|---|---|
| Publish the service, dashboard screenshots, runbook and an incident note | about 14 hours over 3 weeks | repo + notes | Runbook only. | Stop at the end of the step you're on and write two lines about where you stopped. Pick it up from those notes later. |
| Share it with 5 ex-colleagues in ops or platform teams | about 2 hours | 5 messages | Share it with 3 ex-colleagues in ops or platform teams. | Optional. If reaching out feels like too much this week, skip it and put the time into your proof. |
Signal by day 30: Someone asks how you chose your alert thresholds.
Days 31–60: Practise incidents
| Step | Time | Done when | Smaller version | If you need to pause |
|---|---|---|---|---|
| Simulate two more failures and document them | about 8 hours | 2 notes | 1 note. | Stop at the end of the step you're on and write two lines about where you stopped. Pick it up from those notes later. |
| Apply to 8 SRE, production support or L2 support roles | about 4 hours | 8 logged | Apply to 4 SRE, production support or L2 support roles. | Stop sending for now. Keep a list of who you've contacted so you can follow up later without doubling up. |
Signal by day 60: A screening call for SRE, production or application support.
Days 61–90: Interview depth for SRE production support roles
| Step | Time | Done when | Smaller version | If you need to pause |
|---|---|---|---|---|
| Practise a live troubleshooting walkthrough | about 3 hours | rehearsed twice | Once. | Optional. Skip it if the week is full; nothing later depends on it. |
| Post a short write-up on one incident lesson | about 2 hours | post live | DM 3 people. | Write it as a draft and publish later. A saved draft still counts. |
Signal by day 90: A troubleshooting round.
One search that fits your background
The full set of search strings for this move is on the route page. They work on LinkedIn, Naukri and foundit; Instahyre and Cutshort are worth a weekly look too. Add your old job title to any of them with AND, so recruiters who want both skills find you first.
Job-hunt moves that matter for this route
- Search 'SRE', 'site reliability', 'production support' and 'application support' on Naukri and LinkedIn.
- Ask about shift and on-call policy in the first call.
- Lead with the incident note.
Your 30/60/90 quests
XP: learning 20 · proof 60 · outreach 40. Ranks: Wayfinder → Builder → Pathmaker. Progress stays in your browser only.
SRE questions from backend developers
Is production support a step down? It's often a faster way in, and many people move to SRE from it. Our view, based on listings. Do I need Kubernetes? Many listings mention it. Learn the basics after your first proof, not before.
Before you share documents
Be careful with "test tasks" that are really unpaid client work, recruiters asking for fees, or anyone asking for OTPs or UPI PINs. Use official domains only. Report: cybercrime.gov.in / 1930 (India), ReportFraud.ftc.gov (US).
Next: route page · Backend Developer role page · Quiz
Quick quiz: does this path fit?
Answer each, then press Check. Every answer explains itself.
Make your Path Card
A shareable reminder of where you're heading. The day count starts the first time you open this page; quest XP comes from your log above.
Scam check before you apply anywhere
- Real job and gig platforms are free to join. Never pay a "joining" or "training" fee.
- Never share an OTP or UPI PIN — no genuine employer needs them.
- Use official domains only; type the address yourself.
- India: report at cybercrime.gov.in or call 1930.
- US: report at ReportFraud.ftc.gov.
Small steps, every day.
Each quest has a smaller version for hard weeks, and a pause button. Nothing is lost.
Keep exploring
Sources
Checked 25 Oct 2026. We opened every link below ourselves. Search volumes on this site come from OpenSEO keyword research (Oct 2026).
The other facts here are shared with the route page, where each is listed in full with its link.