रात के 3:17 बजे। फोन बज उठता है। Uptime monitor — वो service जो हर कुछ मिनट में तुम्हारी website को ping करती है और down होने पर alert भेजती है — बता रहा है कि तुम्हारी app मर चुकी है। कोई team नहीं। कोई on-call rotation नहीं। कोई SRE (site reliability engineer, वो इंसान जिसकी पूरी job services को alive रखना है) नहीं। बस तुम, तुम्हारा laptop, और adrenaline।

ये hypothetical नहीं है। 1 March को AWS में एक cascading failure शुरू हुआ UAE region से और US-EAST-1 तक फैल गया, 38 services down हो गईं — और solo founders error dashboards को घूर रहे थे बिना किसी को call करने के। फिर 27 March को Cloudflare Pages ने custom domain management को घंटों के लिए तोड़ दिया — मतलब जिन founders ने अपनी marketing sites Pages पर deploy की थीं, उनके domains working hours में internet से गायब हो गए।

मैं ये situation जी चुका हूँ। जितनी बार एक capybara को admit करना चाहिए, उससे ज़्यादा बार। पहले कुछ incidents में मैंने panic किया और चीज़ें और बिगाड़ीं। अब मेरे पास एक playbook है। ये panic को equation से हटाती है और उसकी जगह steps रख देती है। पूरी playbook यहाँ है। 📋

Step 0: अभी कुछ fix मत करो

Counterintuitive लगता है। तुम्हारी app down है। हर second में पैसा जा रहा है, reputation जा रही है, या दोनों। तुम्हारी instinct चीख रही है: अभी fix करो।

लेकिन incident के दौरान सबसे खतरनाक काम है — बिना समझे कि क्या टूटा, कुछ भी करना।

मैंने solo founders को देखा है जो रात 3 बजे SSH — secure terminal से remote server connect — करके production में घुसे, memory से command चलाया, और app के साथ-साथ database भी उड़ा दिया। एक problem दो बन गई। Original fix 20 minute का था। Database recovery में 6 घंटे लगे।

Rule zero: कुछ भी छूने से पहले, 2 minute situation समझने में लगाओ। 20 minute नहीं। दो। Error पढ़ो। Logs check करो। एक hypothesis बनाओ। फिर act करो।

Step 1: Triage — 2 minute

तीन सवाल पूछो:

Service पूरी down है या partially degraded? अपना health endpoint hit करो — एक special URL जो बताता है कि तुम्हारी app के core systems काम कर रहे हैं या नहीं, जैसे एक built-in heartbeat check। अगर app load हो रही है पर API calls (frontend से backend को जाने वाली requests) fail हो रही हैं, तो ये partial है। अगर कुछ भी load नहीं हो रहा, तो total है। इससे urgency decide होती है।

क्या users अभी affected हैं? Analytics check करो। अगर तुम्हारे timezone में रात के 3 बज रहे हैं और तुम्हारे users भी same timezone में हैं, तो शायद पाँच लोगों ने notice किया। अगर तुम्हारे users global हैं, तो सैकड़ों लोग अभी error page देख रहे हैं।

ये कब शुरू हुआ? Monitoring dashboard check करो। अगर 5 minute पहले टूटा है, तो probably last change से जुड़ा है। अगर service 3 घंटे से limp कर रही है और तुम्हें अभी alert मिला, तो तुम्हारी monitoring में gap है जो कल fix करना है।

जवाब लिख लो। Notebook में, खुद को message करो, एक text file में। ये तुम्हारा incident log बन जाएगा — वो single document जो इस outage की पूरी कहानी track करेगा। सुबह तुम खुद को thanks बोलोगे।

Step 2: Communicate करो — 1 minute

भले ही कोई जागा न हो, status update पोस्ट करो। Status page पर, social media पर, Discord पर — जहाँ भी तुम्हारे users check करते हैं। एक line:

"हमें [service] में issue की जानकारी है। Investigate कर रहे हैं। 30 minute में update देंगे।"

Silence एक known outage से ज़्यादा डरावनी है। जो users "investigating" देखते हैं, वो patience से wait करते हैं। जो कुछ नहीं देखते, वो worst assume करते हैं और खुद पोस्ट करने लगते हैं। एक minute की communication तुम्हें 30 minute की शांत investigation दे देती है। ⚙️

Step 3: Obvious चीज़ें check करो — 5 minute

Small companies में 80% incidents का कारण इन पाँच में से एक होता है:

1. Disk full हो गई। df -h चलाओ (disk space human-readable format में दिखाता है)। अगर कोई filesystem 100% दिखा रहा है, तो यही culprit है। Quick fix: oversized log files ढूँढो और delete करो। du -sh /var/log/* बता देगा कौन सी files जगह खा रही हैं।

2. Memory खत्म हो गई। free -h चलाओ (RAM usage दिखाता है)। अगर available memory almost zero है, तो कोई process सब कुछ हड़प रहा है। ps aux --sort=-%mem | head -10 top memory consumers की list देगा — जैसे पता लगाना कि किसने सारे पंखे और AC चालू छोड़ दिए। Bloated process kill करो, service restart करो।

3. Process crash हो गया। systemctl status your-app चलाओ — systemctl Linux का service manager है, वो tool जो तुम्हारी applications को start, stop और monitor करता है। अगर "inactive (dead)" या "failed" बोल रहा है, restart करो: systemctl restart your-app। फिर check करो crash क्यों हुआ: journalctl -u your-app --since "1 hour ago" (journalctl system की event diary पढ़ता है)।

4. SSL certificate expire हो गया। SSL (Secure Sockets Layer) तुम्हारे browser में वो lock icon है — इसका मतलब connection encrypted है। ये certificates expire होते हैं। Let's Encrypt certificates 90 दिन चलते हैं। अगर auto-renewal भूल गए, तो ये 3 AM वाली problem बनने का इंतज़ार कर रही है। Fix: certbot renew && systemctl reload nginx। इस weekend Certbot की automatic renewal set up करो ताकि ये दोबारा न हो।

5. DNS issue। DNS (Domain Name System) internet की phonebook है — ये "yoursite.com" को server address में convert करता है जिसे computers ढूँढ सकें। dig yoursite.com चलाके check करो। अगर resolve नहीं हो रहा, तो DNS provider में issue हो सकता है। या तुम्हारा domain expire हो गया। हाँ, domains expire होते हैं। मैंने funded startups के साथ भी ऐसा होते देखा है।

अगर इन पाँच में से कोई match नहीं करता, तो तुम उन 20% में हो जहाँ real debugging चाहिए। Step 4 पर जाओ।

Step 4: Recent change audit — 5 minute

कुछ तो बदला है। Services अपने आप नहीं टूटतीं — plumbing की तरह, कुछ हिला तो fail होती हैं। पूछो:

  • हाल में कुछ deploy किया? Deploy मतलब नया code live server पर push करना। git log --since="24 hours ago" चलाओ recent code changes देखने के लिए।
  • कोई configuration बदली? Config files की modification timestamps check करो।
  • कोई dependency update हुई? Dependency मतलब किसी और का code जिस पर तुम्हारी app depend करती है — कोई library, framework। Package lock file में recent changes check करो।
  • Hosting provider में issue था? उनका status page check करो।

Sabse common जवाब: तुमने कुछ deploy किया था। Fix: rollback करो — पिछले working version पर वापस जाओ। Debug नहीं। Rollback। Service चालू करो, debug कल करना।

# अगर तुम releases tag करते हो (version labels जैसे v1.2.3):
git checkout v1.2.3
bash deploy.sh

# अगर अभी तक versions tag नहीं करते (आज से शुरू करो):
git revert HEAD
bash deploy.sh

Rollback करना हार जैसा लगता है। नहीं है। ये सबसे professional response है: uptime को ego से ऊपर रखो। Code कल fix करना coffee और daylight के साथ। 🍵

Step 5: 30-minute rule

अगर 30 minute में root cause — असली underlying reason जिसकी वजह से कुछ टूटा, सिर्फ symptom नहीं — नहीं मिला, तो escalate करो। "पर मैं solo founder हूँ। Escalate किसको?"

  • Hosting provider की support को। अगर managed hosting के पैसे दे रहे हो, तो use करो। इसी के लिए तो है।
  • Retainer पर एक contractor। ₹15,000/month भी "साल में दो बार 3 AM पर message कर सकता हूँ" के लिए worth है।
  • Community को। Relevant Discord server, Slack group, या forum। Error पोस्ट करो, logs दो, बताओ क्या try किया। अच्छी communities तेज़ respond करती हैं।
  • AI assistant को। Error Claude या ChatGPT में paste करो: "ये मेरा server error log है। Service 3:17 AM पर crash हुई। मैंने ये check किया: [list]। और क्या देखना चाहिए?" ये तुम्हारे server में SSH नहीं करेगा, पर diagnostic steps suggest कर सकता है जो तुमसे छूट गए।

30-minute rule इसलिए है क्योंकि 3 AM पर आधे घंटे की solo debugging के बाद तुम्हारा judgment खराब होने लगता है। तुम random चीज़ें try करने लगते हो। Live production server पर 3 AM को random changes — ऐसे data permanently गायब होता है।

Step 6: Post-incident morning

Crisis survive कर लिया। अब सो जाओ। Seriously। Postmortem — क्या गलत हुआ और कैसे रोकें इसका structured analysis — कल होगा। Coffee के साथ। Clear head के साथ। 🛁

कल की checklist:

  1. क्या टूटा? एक line में।
  2. Root cause क्या था? "Server crash हो गया" नहीं बल्कि "Misconfigured log rotation ने disk 100% भर दी।"
  3. Impact क्या रहा? Duration, कितने users affected हुए, measurable revenue loss।
  4. Faster detection में क्या रुकावट आई? वो monitoring gap fix करो।
  5. Faster recovery में क्या रुकावट आई? वो step अपनी playbook में add करो।
  6. ये दोबारा कैसे रोकें? इस हफ्ते implement करो। "कभी करेंगे" नहीं। इस हफ्ते।

ये एक file में लिखो। incidents/2026-03-27.md। तुम institutional knowledge बना रहे हो — एक searchable history कि पहले क्या टूटा और किसने fix किया। जब अगला incident आएगा, past-you ने पहले से notes छोड़ रखे होंगे।

Pre-incident setup

Best incident response incident से पहले होता है। इस weekend ये configure करो:

  • Uptime monitoring। UptimeRobot का free tier: 50 monitors, 5-minute intervals। ये तुम्हारी site ping करता है और down होने पर message भेजता है। एक बार set up करो, भूल जाओ। ✅
  • Log rotation। logrotate configure करो — एक Linux utility जो automatically पुरानी log files compress और delete करती है — हर उस log के लिए जो तुम्हारी app produce करती है। जब logs managed हों तो disks नहीं भरतीं।
  • SSL auto-renewal। Certbot एक cron job (एक scheduled task जो automatically timer पर चलती है) के साथ। दोबारा कभी manually certificate renew मत करो।
  • Automated backups। Database dump S3 (Amazon का cloud storage) या किसी भी object storage पर, हर 6 घंटे। Restore process कम से कम एक बार test करो। जो backup तुमने कभी restore नहीं किया, वो backup नहीं उम्मीद है।
  • Rollback script। एक command से पिछले version पर वापस जाओ। 3 AM पर सोचने की ज़रूरत नहीं।

Total setup: एक शांत Saturday afternoon के लगभग 3 घंटे। वो 3 घंटे तुम्हारे business को protect करते हैं अगली बार जब अंधेरे में कुछ टूटे।

जो founders सबसे शांत रहते हैं, वो इसलिए नहीं कि उनका कुछ नहीं टूटता। सबका टूटता है। वो शांत इसलिए रहते हैं क्योंकि उनके पास playbook है। वो पहले भी इससे गुज़र चुके हैं। उन्हें पता है अगला step क्या है। और उन्हें experience से गहराई से पता है — कि panic करने से कभी, एक बार भी, server fix नहीं हुआ। 🫶

incident-response, devops, automation, solo-founder, infrastructure