Status page کیسے بنائیں: Components، Incidents اور Uptime Checks

ایک status page آپ کے صارفین کو ایک ہی جگہ بتاتا ہے کہ آپ کی سروس کام کر رہی ہے یا نہیں۔ اسے بنانے کے لیے آپ کو components کی فہرست چاہیے (website، API، payments، email delivery)، ہر component کی موجودہ حالت، timestamp والے updates کے ساتھ incidents، پچھلے incidents کی تاریخ، اور اختیاری طور پر subscriptions تاکہ لوگوں کو چیک کیے بغیر مسائل کی خبر ملے۔ صفحہ خود سادہ ہے۔ اصل فیصلہ یہ ہے کہ یہ کہاں چلے گا: status page کو اس وقت بھی چلتے رہنا چاہیے جب آپ کی ایپ بند ہو، اس لیے اسے ہوسٹنگ، database اور deploy pipeline میں اس چیز سے الگ رکھیں جس کی یہ رپورٹ کرتا ہے۔

Status page کس لیے ہے

جب کوئی چیز ٹوٹتی ہے تو صارفین تین باتیں جاننا چاہتے ہیں: کیا یہ صرف میرے ساتھ ہو رہا ہے، کیا آپ کو اس کا علم ہے، اور یہ کب ٹھیک ہوگا۔ status page بغیر support tickets کے ہجوم کے تینوں سوالوں کا جواب دیتا ہے۔ وقت کے ساتھ یہ اعتماد بھی پیدا کرتا ہے، کیونکہ incidents کی واضح تاریخ اور ایماندار رپورٹیں دکھاتی ہیں کہ آپ مسائل کو کیسے سنبھالتے ہیں۔

یہ changelog نہیں ہے۔ نئے فیچرز changelog page پر جاتے ہیں؛ outages اور maintenance یہاں آتے ہیں۔

صفحے کو کیا چاہیے

ڈیٹا

Component statuses عموماً ایک مختصر مقررہ فہرست ہوتی ہے: Operational، Degraded performance، Partial outage، Major outage، Under maintenance۔

صفحات

• عوامی status page: ایک مجموعی بینر ("All systems operational" یا سب سے خراب موجودہ status)، ہر component اس کے status کے ساتھ، کوئی فعال incident اس کے updates کے ساتھ، آنے والی maintenance، اور اگر check کا ڈیٹا ہو تو 90 دن کی history کی پٹی۔
• Incident page: ایک incident کے updates کی مکمل timeline، اپنے URL کے ساتھ تاکہ سپورٹ ٹیم اسے لنک کر سکے۔
• History: پچھلے incidents مہینے کے حساب سے۔
• Subscribe: تصدیق کے ساتھ ای میل سائن اپ اور ہر component کی ترجیحات۔
• Admin: incident بنانا، updates پوسٹ کرنا، component statuses بدلنا، maintenance طے کرنا۔

اجازتیں

عوام وہ سب دیکھتی ہے جو شائع ہو۔ صرف آپ کی ٹیم پوسٹ کر سکتی ہے۔ اگر ممکن ہو تو admin login کو اپنی main ایپ کے login سسٹم سے الگ رکھیں، تاکہ آپ کے auth provider کا outage آپ کو اپنے ہی status page سے باہر نہ کر دے۔

اہم فیصلہ: اسے آزاد رکھیں

یہیں زیادہ تر گھر کے بنائے ہوئے status pages ناکام ہوتے ہیں۔ اگر آپ کا status page:

• آپ کی ایپ کے ہی server یا hosting اکاؤنٹ پر چلتا ہے،
• اسی database سے ڈیٹا پڑھتا ہے،
• اسی domain سیٹ اپ یا CDN کنفیگریشن کے پیچھے ہے،
• یا اسی pipeline سے deploy ہوتا ہے،

تو بہت سے outages اسے بھی بند کر دیں گے، عین اسی وقت جب لوگوں کو اس کی سب سے زیادہ ضرورت ہوگی۔ عملی اقدامات:

• الگ hosting۔ مین ایپ سے مختلف project یا provider۔
• اپنا subdomain، جیسے status.example.com، جو DNS میں الگ سے پوائنٹ ہو۔ دیکھیں domains اور DNS کیسے کام کرتے ہیں۔
• اپنا ڈیٹا۔ incidents status page کے اپنے storage میں رہیں، آپ کے ایپ کے database میں نہیں۔
• ایک static fallback۔ کچھ ٹیمیں عوامی صفحہ static بناتی ہیں اور ہر update پر دوبارہ build کرتی ہیں، تاکہ ٹوٹنے کے لیے تقریباً کچھ بھی نہ ہو۔

دستی updates یا خودکار checks

دستی (یہاں سے شروع کریں)

آپ کی ٹیم admin صفحے سے incidents پوسٹ کرتی ہے اور component statuses ہاتھ سے بدلتی ہے۔ عملی طور پر بہت سے status pages اسی طرح کام کرتے ہیں، کیونکہ انسانی فیصلہ ("کچھ کارڈ کی قسموں کے لیے payments سست ہیں") خودکار سرخ نقطے سے زیادہ مفید ہوتا ہے۔

مسائل جلد جاننے کے لیے کسی external uptime monitor کا استعمال کریں جو ہر منٹ کے قریب آپ کی ایپ چیک کرے اور ای میل، SMS یا chat پر خبردار کرے۔ بہت سی monitoring سروسز کا free tier ہوتا ہے۔

خودکار

خودکار نظام کا مطلب ہے کہ کوئی چیز باقاعدگی سے ہر component کو چیک کرے اور اس کا status اپ ڈیٹ کرے۔ اس کے لیے ایسا code چاہیے جو شیڈول پر چلے اور آپ کی مین ایپ کے انفراسٹرکچر سے باہر سے کام کرے۔ دو عام طریقے:

• ایک external monitor آپ کے status page کو کال کرتا ہے ایک webhook کے ذریعے جب کوئی check ناکام ہو یا بحال ہو، اور status page اس component کو اپ ڈیٹ کرتا ہے۔
• status page کی اپنی hosting پر ایک scheduled job ہر component کو ping کرتا ہے اور نتیجہ محفوظ کرتا ہے۔ اس پر بھروسہ کرنے سے پہلے دیکھیں کہ آپ کی hosting scheduled tasks کو کیسے سنبھالتی ہے؛ background jobs چلانے کے بارے میں ہماری گائیڈ اس کے اختیارات بتاتی ہے۔

خودکار تبدیلیاں سست نیٹ ورک پر flap کر سکتی ہیں (اوپر، نیچے، اوپر)۔ status بدلنے سے پہلے دو یا تین ناکام checks کی شرط رکھیں، اور بڑے outage کا اعلان کرنے سے پہلے کسی انسان کی تصدیق لیں۔

incident updates لکھنا

• جلدی پوسٹ کریں۔ "ہم لاگ اِن کی ناکامی کی رپورٹس کی تحقیق کر رہے ہیں" چند منٹ میں، ایک گھنٹے بعد کے کامل پیغام سے بہتر ہے۔
• بتائیں کہ صارفین کو کیا محسوس ہو رہا ہے، نہ کہ اندر کیا ٹوٹا۔
• اگلے update کا وقت بتائیں، اور اسے پورا کریں۔
• حل ہونے پر مختصر خلاصہ لکھیں: کیا ہوا، کتنی دیر رہا، اور آپ کیا بدل رہے ہیں۔

ایک کارآمد پہلا prompt

Parcelio کی ایپ کے لیے ایک الگ status page بناؤ، جو status.parcelio.com پر الگ سے hosted ہو۔ Components: Website، Tracking API، Notifications، Payments، ہر ایک کا status Operational، Degraded performance، Partial outage، Major outage یا Under maintenance ہو۔ عوامی صفحے پر مجموعی بینر ہو جو سب سے خراب موجودہ status استعمال کرے، ہر component اس کے status کے ساتھ، فعال incidents اپنے timestamp والے updates کے ساتھ سب سے نئے پہلے، آنے والی maintenance، اور پچھلے incidents کی مہینے کے حساب سے فہرست۔ ہر incident کا اپنا صفحہ ہو۔ ایک پاس ورڈ سے محفوظ admin صفحہ بناؤ جو incidents بنائے (عنوان، impact، متاثرہ components)، updates پوسٹ کرے (پیغام اور status: Investigating، Identified، Monitoring، Resolved)، component statuses بدلے اور maintenance طے کرے۔ ایک POST /api/check-result endpoint بناؤ جو کسی external monitor سے component کا نام اور up/down قبول کرے، ایک secret token سے محفوظ ہو، اور component کو صرف تین مسلسل down کے بعد Degraded کرے۔ سب کچھ اس ایپ کے اپنے database میں محفوظ کرو۔ سادہ، پرسکون ڈیزائن جو فون پر تیزی سے لوڈ ہو۔

Build کے مراحل

1. عوامی صفحہ اور دستی incidents والا admin۔ یہ اکیلا ہی ایک کام کرنے والا status page ہے۔
2. اسے الگ سے hosting کریں اور ایک subdomain اس کی طرف پوائنٹ کریں۔
3. Incident pages اور history۔
4. Maintenance windows۔
5. Subscriptions۔ دو مرحلوں والی تصدیق کے ساتھ ای میل سائن اپ، اور نئے incidents اور updates پر notifications۔ ای میل کے لیے ایک provider درکار ہے؛ دیکھیں اپنی ایپ سے ای میل کیسے بھیجیں۔
6. Monitor webhook اگر آپ خودکار status تبدیلیاں چاہتے ہیں۔
7. Drill کریں۔ ایک جعلی incident بنائیں، updates پوسٹ کریں، اسے حل کریں، ای میلز چیک کریں، پھر اسے delete کریں۔

عام غلطیاں

• اسے ایپ کے ساتھ hosting کرنا۔ سب سے عام اور سب سے سنگین غلطی۔
• ایسا صفحہ جو ہمیشہ "All systems operational" دکھائے۔ اگر یہ کبھی مسائل نہیں دکھاتا تو صارفین اس پر بھروسہ کرنا چھوڑ دیتے ہیں۔
• Timestamps یا time zone نہ ہونا۔ وقت ہمیشہ zone کے ساتھ دکھائیں۔
• admin صفحے کے لیے اپنی مین ایپ کے login پر انحصار۔
• updates کے درمیان خاموشی۔ "کوئی تبدیلی نہیں، ابھی بھی کام جاری ہے" ایک درست update ہے۔
• خودکار statuses کا flap کرنا۔ تبدیلی سے پہلے بار بار ناکامی کی شرط رکھیں۔

کب hosted status page سروس بہتر انتخاب ہے

Hosted status page سروسز اسی independence کے مسئلے کے لیے بنی ہیں: یہ الگ انفراسٹرکچر پر چلتی ہیں، ای میل اور SMS کے ذریعے subscriber notifications سنبھالتی ہیں، اور اکثر monitoring اور incident tools کے ساتھ integrations بھی دیتی ہیں۔ اگر uptime وہ چیز ہے جس کے لیے گاہک ادائیگی کرتے ہیں، یا آپ پر incidents رپورٹ کرنے کی معاہداتی ذمہ داری ہے، تو ایک مخصوص سروس عموماً اس کے قابل ہوتی ہے۔ چھوٹی ٹیموں کے لیے بہت سی سروسز کا free یا کم قیمت tier ہوتا ہے، اس لیے بنانے سے پہلے چیک کریں۔

اپنا بنائیں جب آپ design اور الفاظ پر مکمل کنٹرول چاہتے ہوں، جب آپ کی ضروریات سادہ ہوں (چند components، دستی updates)، یا جب status page وہ چیز ہو جو آپ دوسروں کے لیے بنا رہے ہوں۔

Mythex کے ساتھ بنانا

Mythex پر آپ status page کو اپنے الگ project کے طور پر بنا سکتے ہیں، جو مین ایپ سے الگ ہو اور اس کی اپنی hosting اور اپنا database ہو۔ اسے chat میں بیان کریں، live preview میں دیکھیں، پھر publish کریں اور status.yourdomain.com جیسا subdomain جوڑیں (custom domains Pro پر دستیاب ہیں)۔ یاد رکھیں کہ شائع شدہ Mythex ایپس اور ان کے databases بیکار ہونے پر سو جاتے ہیں اور اگلی visit پر جاگ جاتے ہیں، اس لیے خاموش وقت کے بعد پہلی load سست ہو سکتی ہے؛ ایک سادہ، ہلکا صفحہ مدد کرتا ہے۔

Mythex شیڈول پر چلنے والے jobs کی دستاویز نہیں کرتا، اس لیے خودکار checks کے لیے کوئی external uptime monitor استعمال کریں جو آپ کے status page کے webhook endpoint کو کال کرے (دیکھیں webhooks recipe)۔ subscribers کو ای میل alerts آپ کے اپنے provider سے جاتے ہیں، جس کی key ایک project secret کے طور پر محفوظ ہوتی ہے (send email recipe)۔

سوالات