Cloudflare आउटेज, क्षेत्रीय CDN विफलताएं और एज-लेवल डिग्रेडेशन हमेशा स्टेटस पेज पर नहीं दिखते। जब आपके CDN का टोक्यो PoP डाउन हो लेकिन उनका ग्लोबल स्टेटस ग्रीन दिखाए, वर्जीनिया से आपकी मॉनिटरिंग इसे नहीं पकड़ पाएगी।
क्षेत्रीय आउटेज डिटेक्शन के लिए वहां से मॉनिटरिंग चाहिए जहां आपके उपयोगकर्ता वास्तव में हैं — न कि सिर्फ वहां जहां आपका इंफ्रास्ट्रक्चर है।
रात 3 बजे हैं। आपके ऑन-कॉल इंजीनियर को कस्टमर सक्सेस से पिंग मिलता है: "सिंगापुर के तीन एंटरप्राइज़ ग्राहकों ने रिपोर्ट किया है कि वे ऐप एक्सेस नहीं कर पा रहे। करीब दो घंटे पहले शुरू हुआ।"
आप अपना मॉनिटरिंग डैशबोर्ड चेक करते हैं — सब कुछ हरा। Cloudflare का स्टेटस पेज — ऑपरेशनल। AWS — कोई इंसिडेंट नहीं। आपका APM — खुशनुमा ग्राफ। तो आप ग्राहकों से दोबारा कोशिश करने, कैश क्लियर करने, नेटवर्क चेक करने को कहते हैं।
लेकिन यह जारी रहता है। उसी क्षेत्र से और टिकट आते हैं। अंत में, कोई सिंगापुर VPS से traceroute चलाता है और पता चलता है: ट्रैफिक एक Cloudflare एज पर जा रहा है जो 502 लौटा रहा है। CDN में एक PoP को प्रभावित करने वाला क्षेत्रीय आउटेज है — और आपके मॉनिटरिंग स्टैक में से कुछ भी उस क्षेत्र से चेक नहीं कर रहा।
दो घंटे का डाउनटाइम। एक विशिष्ट भौगोलिक क्षेत्र के लिए। शून्य अलर्ट। यही वह ब्लाइंड स्पॉट है जिसके बारे में यह पेज है।
चाहे यह Cloudflare आउटेज हो, Fastly एज फेलियर हो, या Akamai रीजनल डिग्रेडेशन — इन समस्याओं का पता लगाने के लिए प्रभावित क्षेत्रों से मॉनिटरिंग चाहिए। यही तरीका है कि आप समस्याओं को कस्टमर एस्केलेशन बनने से पहले पकड़ सकें।
इंटरनेट एक अकेला नेटवर्क नहीं है। सिडनी से एक रिक्वेस्ट फ्रैंकफर्ट से एक रिक्वेस्ट की तुलना में पूरी तरह अलग इंफ्रास्ट्रक्चर से होकर गुजरती है। जब उस क्षेत्रीय पथ का कोई भी हिस्सा विफल होता है, तो केवल उस क्षेत्र के उपयोगकर्ता प्रभावित होते हैं।
Cloudflare, Fastly और Akamai जैसे CDN वैश्विक स्तर पर सैकड़ों PoP (Points of Presence) संचालित करते हैं। जब किसी विशिष्ट एज सर्वर या PoP में हार्डवेयर विफलता, गलत कॉन्फ़िगरेशन, या क्षमता की समस्या होती है — तो केवल उस एज पर रूट होने वाले उपयोगकर्ता प्रभावित होते हैं। CDN का ग्लोबल स्टेटस "ऑपरेशनल" रहता है क्योंकि 95% एज ठीक हैं।
उदाहरण: जून 2022 में, Cloudflare में नेटवर्क कॉन्फ़िगरेशन बदलाव के कारण 19 डेटा सेंटरों को प्रभावित करने वाला 30 मिनट का आउटेज हुआ। उन क्षेत्रों के उपयोगकर्ताओं को एरर दिखे; बाकी जगहों के उपयोगकर्ताओं ने कुछ असामान्य अनुभव नहीं किया।
DNS हर रिक्वेस्ट का पहला कदम है। जब Cloudflare का 1.1.1.1 या आपके CDN के DNS सर्वर किसी विशिष्ट क्षेत्र में समस्या अनुभव करते हैं — गलत कॉन्फ़िगर्ड एनीकास्ट रूट, ओवरलोडेड नेमसर्वर — उस क्षेत्र के उपयोगकर्ता आपका डोमेन रिज़ॉल्व नहीं कर पाते। उनके ब्राउज़र पर बस "DNS_PROBE_FINISHED_NXDOMAIN" दिखता है।
उदाहरण: क्षेत्रीय DNS समस्याएं ISP-लेवल फिल्टरिंग, लोकल रिज़ॉल्वर समस्याओं, या एनीकास्ट रूटिंग मुद्दों के कारण हो सकती हैं जो केवल कुछ भौगोलिक क्षेत्रों को प्रभावित करती हैं।
BGP रूट लीक, हाईजैक, और गलत कॉन्फ़िगरेशन ट्रैफिक को गैर-इष्टतम पथों पर रीडायरेक्ट कर सकते हैं या पूरी तरह ब्लैकहोल कर सकते हैं। जब किसी क्षेत्र में एक प्रमुख कैरियर को रूटिंग समस्या होती है, तो उस क्षेत्र से आपके CDN या ऑरिजिन तक का ट्रैफिक विफल हो सकता है — भले ही दोनों एंडपॉइंट पूरी तरह सही काम कर रहे हों।
उदाहरण: BGP इंसिडेंट नियमित रूप से हजारों नेटवर्क को प्रभावित करते हैं। एक गलत कॉन्फ़िगर्ड AS पथ आपकी साइट को पूरे देशों से घंटों तक अनुपलब्ध बना सकता है, जबकि आपकी मॉनिटरिंग लोकेशन से सब ठीक दिखता है।
विशिष्ट देशों की प्रमुख ISP में पीयरिंग विवादों, कंजेशन, या इंफ्रास्ट्रक्चर समस्याओं के कारण आपके CDN से कनेक्टिविटी खराब हो सकती है। ऑस्ट्रेलिया में Telstra के उपयोगकर्ताओं को विफलता का अनुभव हो सकता है जबकि उसी शहर में Optus के उपयोगकर्ताओं को कोई समस्या नहीं — क्योंकि ट्रैफिक अलग-अलग पथों से होकर गुजरता है।
उदाहरण: ISP और क्लाउड प्रोवाइडरों के बीच पीयरिंग विवादों ने ऐतिहासिक रूप से विशिष्ट बाजारों में लाखों उपयोगकर्ताओं को प्रभावित करने वाले कई-सप्ताह के डिग्रेडेशन का कारण बना है।
सामान्य सूत्र: ये सभी विफलताएं भौगोलिक रूप से सीमित हैं। आपका ऑरिजिन चालू है। आपकी CDN कॉन्फ़िगरेशन सही है। लेकिन आपके एज और किसी विशिष्ट क्षेत्र के उपयोगकर्ताओं के बीच कहीं कुछ टूट गया है — और वर्जीनिया में एक जगह से चेक करने वाली आपकी मॉनिटरिंग के पास इसे पकड़ने का कोई तरीका नहीं है।
अधिकांश अपटाइम मॉनिटरिंग एक सरल समस्या के लिए डिज़ाइन की गई थी: "क्या सर्वर जवाब दे रहा है?" CDN-एक्सेलरेटेड साइटों के लिए जो वैश्विक उपयोगकर्ताओं को सेवा देती हैं, यह अब सही सवाल नहीं है।
अधिकांश मॉनिटरिंग सेवाएं डिफ़ॉल्ट रूप से US या EU की कुछ लोकेशन से चेक करती हैं। अगर Cloudflare का सिंगापुर PoP डाउन हो जाए, तो ओरेगन से आपकी चेक तब भी सफल होगी — यह एक अलग, स्वस्थ एज तक पहुंचती है। इस बीच, आपके APAC उपयोगकर्ता 502 एरर देख रहे हैं।
AWS से Cloudflare तक चेक चलाना क्लाउड बैकबोन कनेक्टिविटी का उपयोग करता है — ऑप्टिमाइज़्ड पथ जो वास्तविक उपयोगकर्ता ट्रैफिक का प्रतिनिधित्व नहीं करते। AWS ap-southeast-1 से आपकी सिंथेटिक चेक उस सटीक नेटवर्क पथ को बायपास कर सकती है जो लोकल ISP के उपयोगकर्ताओं के लिए विफल हो रहा है।
CDN स्टेटस पेज उनके आंतरिक दृश्य को दर्शाते हैं, जो अक्सर सैकड़ों PoP में एकत्रित होता है। 5% इंफ्रास्ट्रक्चर को प्रभावित करने वाली क्षेत्रीय समस्या स्टेटस पेज अपडेट को ट्रिगर नहीं कर सकती — लेकिन उस 5% में पूरा दक्षिण-पूर्व एशिया शामिल हो सकता है।
HTTP चेक आपको बताती हैं कि रिक्वेस्ट सफल हुई या विफल, लेकिन यह नहीं कि कहां विफल हुई। प्रभावित क्षेत्र से traceroute और लेटेंसी ब्रेकडाउन डेटा के बिना, आप यह निर्धारित नहीं कर सकते कि समस्या DNS, किसी विशिष्ट नेटवर्क हॉप, या आपके CDN एज में है।
Cloudflare के 310+ PoP हैं। अगर आपकी मॉनिटरिंग 3 लोकेशन से चेक करती है, तो आप उन एज के 1% से भी कम को सत्यापित कर रहे हैं जिन पर आपके उपयोगकर्ता पहुंच सकते हैं। यह आउटेज डिटेक्शन नहीं है — यह बस अच्छे की उम्मीद करना है।
Cloudflare आउटेज या क्षेत्रीय CDN विफलता का पता न चलने वाला हर मिनट, आप उन बाजारों में उपयोगकर्ता, राजस्व और विश्वास खो रहे हैं जिनकी सेवा करने के बारे में आप शायद जानते भी नहीं।
उस समय क्षेत्र के व्यापारिक घंटों के दौरान एक क्षेत्रीय आउटेज घंटों के लेनदेन, साइनअप, या API कॉल की लागत ला सकता है। उपयोगकर्ता "आपकी साइट मेरे लिए डाउन है" ईमेल नहीं भेजते — वे बस चले जाते हैं। आपको बाद में क्षेत्रीय मेट्रिक्स में गिरावट दिखेगी, बिना किसी स्पष्ट कारण के।
एंटरप्राइज़ ग्राहकों के SLA होते हैं। जब वे आपके प्लेटफॉर्म तक नहीं पहुंच पाते और आपको पता ही नहीं कि कोई समस्या थी, तो यह एक खराब बातचीत होती है। "हमने आउटेज डिटेक्ट नहीं किया" ऐसी प्रतिक्रिया नहीं है जो विश्वास बनाती है — खासकर जब वे विश्वसनीयता के लिए भुगतान कर रहे हैं।
Googlebot विश्व भर की कई जगहों से क्रॉल करता है। अगर किसी क्षेत्र में आपका CDN एज एरर या धीमी प्रतिक्रिया दे रहा है, तो यह क्रॉल बजट, Core Web Vitals मूल्यांकन, और अंततः रैंकिंग को प्रभावित करता है। बिना किसी स्पष्ट कारण के विशिष्ट बाजारों में ट्रैफिक में गिरावट दिख सकती है।
MTTR (मीन टाइम टू रिकवरी) तब शुरू होता है जब आप समस्या का पता लगाते हैं। अगर एक क्षेत्रीय Cloudflare आउटेज 2 घंटे तक उपयोगकर्ताओं को प्रभावित करता है और आपको ग्राहक टिकट से पता चलता है, तो आपके प्रभावी MTTR में 2 घंटे जुड़ जाते हैं। सक्रिय डिटेक्शन ही वास्तविक डाउनटाइम प्रभाव को कम करने का एकमात्र तरीका है।
क्षेत्रीय आउटेज डिटेक्शन के लिए वहां से मॉनिटरिंग चाहिए जहां आपके उपयोगकर्ता हैं, साथ ही विफलताओं की पहचान करने के लिए नैदानिक गहराई।
प्रत्येक मॉनिटरिंग लोकेशन अलग-अलग CDN एज तक पहुंचती है और अलग-अलग नेटवर्क पथों से गुजरती है। क्षेत्रीय आउटेज का पता लगाने के लिए, आपको हर उस क्षेत्र में नोड चाहिए जहां आपका महत्वपूर्ण ट्रैफिक आता है — एशिया-पैसिफिक, यूरोप, अमेरिका, मध्य पूर्व, अफ्रीका। सिर्फ "अंतर्राष्ट्रीय" नहीं — विशेष रूप से जहां आपके उपयोगकर्ता हैं।
50+ लोकेशन से मॉनिटरिंग प्रमुख CDN PoP और ISP पथों को कवर करती है।
जब सिंगापुर से चेक विफल हो लेकिन बाकी सब जगह से सफल हो, तो आपको जानना होगा: DNS है? कोई विशिष्ट नेटवर्क हॉप? CDN एज? प्रभावित लोकेशन से traceroute और MTR मूल कारण का निदान करने और Cloudflare, ISP, या होस्टिंग प्रोवाइडर को एस्केलेट करने के लिए आवश्यक सबूत प्रदान करते हैं।
डायग्नोस्टिक डेटा "कुछ टूटा है" को कार्रवाई योग्य मूल कारण में बदलता है।
टोक्यो से 400ms सामान्य है, या Cloudflare एज डिग्रेडेशन है? लोकेशन-वार ऐतिहासिक डेटा बेसलाइन बनाता है जो आपको धीमी विफलताओं का पता लगाने देता है — लेटेंसी बढ़ोतरी जो हार्ड फेलियर ट्रिगर नहीं करती लेकिन उपयोगकर्ता अनुभव को खराब करती है। पूर्ण आउटेज बनने से पहले क्षेत्रीय CDN समस्या पकड़ सकते हैं।
बेसलाइन आउटेज बनने से पहले डिग्रेडेशन पकड़ती हैं।
उपयोगकर्ताओं द्वारा रिपोर्ट करने से पहले Cloudflare आउटेज और क्षेत्रीय CDN विफलताओं को पकड़ने वाली मॉनिटरिंग लागू करने के लिए चरण-दर-चरण गाइड।
अपने एनालिटिक्स चेक करें ताकि पता चले कि आपके उपयोगकर्ता कहां हैं। अगर ट्रैफिक का 20% एशिया-पैसिफिक से आता है, तो आपको वहां कई मॉनिटरिंग नोड चाहिए — सिंगापुर, टोक्यो, सिडनी, मुंबई। मॉनिटरिंग कवरेज को वास्तविक उपयोगकर्ता वितरण से मिलाएं।
अपने प्राइमरी URL के लिए HTTP मॉनिटर सेट करें जो Cloudflare या आपके CDN से होकर गुजरते हैं। इन्हें सीधे ऑरिजिन नहीं बल्कि CDN एज तक पहुंचना चाहिए। अपने ऐप डोमेन, API एंडपॉइंट, और किसी भी महत्वपूर्ण पब्लिक पेज को शामिल करें।
अलग-अलग क्षेत्रों की अलग-अलग बेसलाइन लेटेंसी होती है। समझदार थ्रेशोल्ड कॉन्फ़िगर करें: यूरोप से 500ms स्वीकार्य हो सकता है, लेकिन US-East से (जब आपका ऑरिजिन वहां हो) 500ms CDN एज समस्या का संकेत है। यथार्थवादी बेसलाइन सेट करने के लिए ऐतिहासिक डेटा का उपयोग करें।
सिर्फ तब नहीं जब सभी लोकेशन विफल हों, बल्कि जब विशिष्ट क्षेत्र विफल हों तब अलर्ट सेट करें। सिंगापुर-ओनली विफलता भी जानने योग्य आउटेज है। उच्च-प्राथमिकता अलर्ट Slack, PagerDuty, या अपने इंसिडेंट मैनेजमेंट सिस्टम पर रूट करें।
जब अलर्ट आए, तो आपको जल्दी निर्धारित करना होगा: Cloudflare की समस्या है? नेटवर्क पथ की समस्या? DNS? मॉनिटरिंग लोकेशन से ऑन-डिमांड traceroute और MTR सक्षम करें ताकि तुरंत डायग्नोस्टिक डेटा एकत्र कर सकें।
प्रक्रिया का दस्तावेजीकरण करें: Cloudflare क्षेत्रीय आउटेज को कैसे सत्यापित करें। Cloudflare का स्टेटस API कहां चेक करें। सबूत के साथ टिकट कैसे खोलें। कौन सी शमन योजनाएं लागू कर सकते हैं (फेलओवर, कैश बायपास, आदि)। यह तैयार रखने से MTTR काफी कम हो जाता है।
क्षेत्र-वार लेटेंसी और अपटाइम की समीक्षा करने के लिए साप्ताहिक कैलेंडर रिमाइंडर सेट करें। पैटर्न देखें: APAC लगातार धीमा है? किसी विशिष्ट लोकेशन में नियमित ब्लिप हैं? सक्रिय समीक्षा उपयोगकर्ताओं पर महत्वपूर्ण प्रभाव पड़ने से पहले धीमे डिग्रेडेशन को पकड़ती है।
उन सेवाओं के लिए जहां क्षेत्रीय आउटेज अस्वीकार्य है, मल्टी-CDN रणनीति पर विचार करें जहां DNS प्रोवाइडरों के बीच फेलओवर कर सके। इसके लिए प्रत्येक CDN की स्वतंत्र मॉनिटरिंग और ट्रैफिक स्विच करने वाला ऑटोमेशन चाहिए। यह जटिलता है, लेकिन यह रिज़िलिएंस है।
Latency Global ठीक इसी तरह की समस्या का पता लगाने के लिए बनाया गया था — Cloudflare आउटेज, क्षेत्रीय CDN विफलताएं, और नेटवर्क समस्याएं जो सिंगल-लोकेशन मॉनिटरिंग से छूट जाती हैं। हम 6 महाद्वीपों में 70+ वास्तविक लोकेशन से मॉनिटर करते हैं, सभी प्रमुख CDN PoP क्षेत्रों को कवर करते हुए।
हर चेक में पूर्ण टाइमिंग ब्रेकडाउन शामिल है — DNS रिज़ॉल्यूशन, TCP कनेक्ट, TLS हैंडशेक, TTFB, और कुल रिस्पॉन्स टाइम। जब किसी विशिष्ट क्षेत्र से कुछ विफल होता है, तो आप उस लोकेशन से traceroute और MTR चला सकते हैं ताकि नेटवर्क पथ में ठीक उस जगह की पहचान कर सकें जहां समस्या हुई। मूल्य निर्धारण सीधा है: $5/month में 5 मॉनिटर, सभी लोकेशन शामिल।
क्षेत्रीय आउटेज डिटेक्शन के लिए कई जगहों पर इंफ्रास्ट्रक्चर चाहिए — इसीलिए अधिकांश मॉनिटरिंग टूल या तो यह ऑफर नहीं करते या एंटरप्राइज़ कीमतें लेते हैं। हम जो मायने रखता है उस पर ध्यान केंद्रित करते हैं: कवरेज और डायग्नोस्टिक गहराई।
क्षेत्रीय CDN आउटेज तब होता है जब CDN नेटवर्क में विशिष्ट एज सर्वर या PoP (Points of Presence) विफल होते हैं या खराब प्रदर्शन करते हैं, जबकि अन्य एज सामान्य रूप से काम करते रहते हैं। उदाहरण के लिए, Cloudflare के सिंगापुर PoP में समस्या हो सकती है जबकि उनके US और यूरोपीय एज ठीक काम करें। प्रभावित एज के माध्यम से रूट होने वाले उपयोगकर्ताओं को एरर या धीमा प्रदर्शन अनुभव होता है; बाकी उपयोगकर्ता कुछ नहीं नोटिस करते। ये आउटेज उस मॉनिटरिंग को दिखाई नहीं देते जो केवल अप्रभावित क्षेत्रों से चेक करती है।
CDN स्टेटस पेज आमतौर पर प्रति-PoP स्वास्थ्य नहीं, बल्कि समग्र वैश्विक स्टेटस दिखाते हैं। जब 5% एज प्रभावित होते हैं, तो समग्र स्टेटस "ऑपरेशनल" रह सकता है क्योंकि 95% इंफ्रास्ट्रक्चर काम कर रहा है। स्टेटस पेज में अपडेट में भी देरी होती है — समस्याओं को पता लगाने, सत्यापित करने और पोस्ट करने में समय लगता है। इसके अलावा, कुछ समस्याएं सार्वजनिक प्रकटीकरण की सीमा पूरी नहीं करतीं लेकिन फिर भी आपके उपयोगकर्ताओं को प्रभावित करती हैं। कई लोकेशन से स्वतंत्र मॉनिटरिंग ही क्षेत्रीय उपलब्धता की वास्तविक स्थिति जानने का एकमात्र तरीका है।
कम से कम, आपको हर प्रमुख क्षेत्र में मॉनिटरिंग लोकेशन चाहिए जहां आपके उपयोगकर्ता हैं: न्यूनतम उत्तरी अमेरिका, यूरोप, और एशिया-पैसिफिक। बेहतर कवरेज के लिए, विश्व भर में वितरित 50+ लोकेशन अधिकांश क्षेत्रीय समस्याओं को पकड़ेंगी। मुख्य बात मॉनिटरिंग कवरेज को आपके उपयोगकर्ता भूगोल से मिलाना है — अगर 30% उपयोगकर्ता APAC में हैं, तो आपको वहां कई नोड चाहिए (सिंगापुर, टोक्यो, सिडनी, मुंबई)। हर CDN PoP से मिलान नहीं, बल्कि प्रमुख क्षेत्रीय समूहों को कवर करना महत्वपूर्ण है।
पहले, डायग्नोस्टिक सबूत इकट्ठा करें: प्रभावित लोकेशन से traceroute और MTR, HTTP रिस्पॉन्स कोड और टाइमिंग डेटा, और टाइमस्टैम्प। Cloudflare के स्टेटस पेज और सोशल मीडिया पर किसी भी स्वीकृति के लिए जांचें। अगर यह स्पष्ट रूप से Cloudflare की समस्या है, तो अपने सबूत के साथ सपोर्ट टिकट खोलें। तत्काल शमन के लिए, विचार करें: प्रभावित क्षेत्र के लिए Cloudflare को अस्थायी रूप से बायपास करना (अगर आपका ऑरिजिन संभाल सकता है), मल्टी-CDN क्षमता होने पर बैकअप CDN सक्षम करना, या Cloudflare द्वारा समाधान करने तक समस्या को स्वीकार करने के लिए अपना स्टेटस पेज अपडेट करना। इंसिडेंट-बाद समीक्षा के लिए सब कुछ दस्तावेज़ करें।
हां, उचित मॉनिटरिंग इंस्ट्रुमेंटेशन के साथ। पूर्ण HTTP चेक टाइमिंग दिखाती है: DNS रिज़ॉल्यूशन टाइम (DNS विफल या धीमा है तो DNS समस्या पता चलती है), TCP कनेक्ट टाइम (नेटवर्क पथ समस्याएं), TLS हैंडशेक टाइम (सर्टिफिकेट या क्रिप्टो समस्याएं), और TTFB/रिस्पॉन्स टाइम (ऑरिजिन या एज प्रोसेसिंग समस्याएं)। Traceroute नेटवर्क पथ दिखाता है और कहां पैकेट ड्रॉप या देरी हो रही है। प्रभावित क्षेत्र बनाम स्वस्थ क्षेत्रों के इस डेटा की तुलना करके, आप रिक्वेस्ट चेन में ठीक उसी जगह की पहचान कर सकते हैं जहां विफलता हो रही है।
1-मिनट चेक इंटरवल के साथ, शुरू होने के 1-2 मिनट के भीतर आउटेज का पता लगा सकते हैं। अधिकांश मॉनिटरिंग सेवाएं क्षणिक ब्लिप पर अलर्ट से बचने के लिए 2-3 लगातार विफलताओं के बाद पुष्टि करती हैं, इसलिए यथार्थवादी डिटेक्शन टाइम 2-5 मिनट है। इसकी तुलना ग्राहक-रिपोर्टेड आउटेज से करें, जो सपोर्ट टिकट के माध्यम से सामने आने में घंटों लग सकते हैं। MTTR में अंतर महत्वपूर्ण है — 5 मिनट बनाम 2 घंटे मतलब उपयोगकर्ता प्रभाव बहुत अलग।
बिल्कुल। Fastly, Akamai, AWS CloudFront, Google Cloud CDN, Azure CDN, और कोई भी अन्य CDN क्षेत्रीय आउटेज अनुभव कर सकता है। वही सिद्धांत लागू होते हैं: CDN में वितरित इंफ्रास्ट्रक्चर है, और किसी भी वितरित सिस्टम में आंशिक विफलताएं हो सकती हैं। डिटेक्शन दृष्टिकोण वही है — चाहे आप कोई भी CDN उपयोग करें, विशिष्ट एज या क्षेत्रों को प्रभावित करने वाली समस्याओं को पकड़ने के लिए कई वैश्विक लोकेशन से मॉनिटर करें।
CDN स्टेटस पेज और ग्राहक टिकट पर निर्भर रहकर क्षेत्रीय आउटेज जानना बंद करें। अपने एंडपॉइंट जोड़ें, मॉनिटरिंग लोकेशन चुनें, और जानें जब Cloudflare, Fastly, या आपके स्टैक का कोई भी हिस्सा किसी भी क्षेत्र में विफल हो — मिनटों में।
$5/month • 70+ लोकेशन (+40 और जल्द ही) • कोई कॉन्ट्रैक्ट नहीं • कभी भी रद्द करें