സ്റ്റാറ്റസ് പേജ് എങ്ങനെ നിർമ്മിക്കാം: ഘടകങ്ങൾ, സംഭവങ്ങൾ, അപ്‌ടൈം പരിശോധനകൾ

നിങ്ങളുടെ സേവനം പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് ഒരിടത്ത് നിന്ന് ഉപയോക്താക്കളോട് പറയുന്ന പേജാണ് സ്റ്റാറ്റസ് പേജ്. ഇത് നിർമ്മിക്കാൻ ഘടകങ്ങളുടെ പട്ടിക വേണം (വെബ്സൈറ്റ്, പേയ്‌മെന്റ്, ഇമെയിൽ, API പോലുള്ളവ), ഓരോന്നിന്റെയും നിലവിലെ സ്റ്റാറ്റസ്, സമയം രേഖപ്പെടുത്തിയ അപ്‌ഡേറ്റുകളോടു കൂടിയ സംഭവങ്ങൾ, പഴയ സംഭവങ്ങളുടെ ചരിത്രം, ആവശ്യമെങ്കിൽ സബ്സ്ക്രിപ്ഷനുകൾ. പേജ് തന്നെ ലളിതമാണ്. പ്രധാന തീരുമാനം അത് എവിടെ പ്രവർത്തിക്കുന്നു എന്നതാണ്: നിങ്ങളുടെ ആപ്പ് തകരാറിലാകുമ്പോഴും സ്റ്റാറ്റസ് പേജ് ലഭ്യമായിരിക്കണം. അതുകൊണ്ട് അത് റിപ്പോർട്ട് ചെയ്യുന്ന ആപ്പുമായി ഹോസ്റ്റിങ് അക്കൗണ്ടോ ഡാറ്റാബേസോ ഡിപ്ലോയ് പൈപ്പ്‌ലൈനോ പങ്കിടരുത്.

സ്റ്റാറ്റസ് പേജിന്റെ ഉദ്ദേശ്യം

എന്തെങ്കിലും തകരാറിലാകുമ്പോൾ ഉപയോക്താക്കൾക്ക് മൂന്ന് കാര്യങ്ങൾ അറിയണം: ഇത് എനിക്ക് മാത്രമാണോ, നിങ്ങൾക്ക് അറിയാമോ, എപ്പോൾ ശരിയാകും. സ്റ്റാറ്റസ് പേജ് ഒരു പ്രളയം പോലെ സപ്പോർട്ട് ടിക്കറ്റുകൾ വരാതെ ഇതെല്ലാം മറുപടി നൽകുന്നു. കാലക്രമേണ ഇത് വിശ്വാസവും വളർത്തുന്നു, കാരണം സത്യസന്ധമായ വിശദീകരണങ്ങളോടു കൂടിയ സംഭവ ചരിത്രം പ്രശ്നങ്ങളെ നിങ്ങൾ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു എന്ന് കാണിക്കുന്നു.

ഇത് ഒരു ചേഞ്ച്‌ലോഗ് അല്ല. പുതിയ ഫീച്ചറുകൾ ചേഞ്ച്‌ലോഗ് പേജിൽ പോകുന്നു; തകരാറുകളും അറ്റകുറ്റപ്പണികളും ഇവിടെ.

പേജിന് വേണ്ടവ

ഡാറ്റ

ഘടക സ്റ്റാറ്റസുകൾ സാധാരണയായി ചെറിയ നിശ്ചിത പട്ടികയാണ്: Operational, Degraded performance, Partial outage, Major outage, Under maintenance.

പേജുകൾ

• പൊതു സ്റ്റാറ്റസ് പേജ്: മൊത്തത്തിലുള്ള ബാനർ (“എല്ലാ സിസ്റ്റങ്ങളും പ്രവർത്തിക്കുന്നു” അല്ലെങ്കിൽ ഏറ്റവും മോശം നിലവിലെ സ്റ്റാറ്റസ്), ഓരോ ഘടകവും അതിന്റെ സ്റ്റാറ്റസോടെ, സജീവമായ സംഭവവും അതിന്റെ അപ്‌ഡേറ്റുകളും, വരാനിരിക്കുന്ന അറ്റകുറ്റപ്പണി, ചെക്ക് ഡാറ്റ ഉണ്ടെങ്കിൽ 90 ദിവസത്തെ ചരിത്ര സ്ട്രിപ്പ്.
• സംഭവ പേജ്: ഒരു സംഭവത്തിന്റെ പൂർണ്ണ അപ്‌ഡേറ്റ് ടൈംലൈൻ, സ്വന്തം URL-ൽ, സപ്പോർട്ടിന് ലിങ്ക് ചെയ്യാൻ.
• ചരിത്രം: മാസം തിരിച്ചുള്ള പഴയ സംഭവങ്ങൾ.
• സബ്സ്ക്രൈബ്: സ്ഥിരീകരണത്തോടെ ഇമെയിൽ രജിസ്ട്രേഷനും ഘടകം തിരിച്ചുള്ള മുൻഗണനകളും.
• അഡ്മിൻ: സംഭവം സൃഷ്ടിക്കുക, അപ്‌ഡേറ്റുകൾ പോസ്റ്റ് ചെയ്യുക, ഘടക സ്റ്റാറ്റസ് മാറ്റുക, അറ്റകുറ്റപ്പണി ഷെഡ്യൂൾ ചെയ്യുക.

അനുമതികൾ

പ്രസിദ്ധീകരിച്ചതെല്ലാം പൊതുജനത്തിന് കാണാം. പോസ്റ്റ് ചെയ്യാൻ നിങ്ങളുടെ ടീമിന് മാത്രം അധികാരം. കഴിയുമെങ്കിൽ അഡ്മിൻ ലോഗിൻ നിങ്ങളുടെ പ്രധാന ആപ്പിന്റെ ലോഗിൻ സിസ്റ്റത്തിൽ നിന്ന് വേറിട്ട് സൂക്ഷിക്കുക. അങ്ങനെ ഓത്ത് പ്രൊവൈഡർ തകരാറിലായാലും നിങ്ങൾക്ക് സ്വന്തം സ്റ്റാറ്റസ് പേജിൽ നിന്ന് പുറത്താകില്ല.

പ്രധാന തീരുമാനം: സ്വതന്ത്രമായി നിർത്തുക

വീട്ടിലുണ്ടാക്കുന്ന സ്റ്റാറ്റസ് പേജുകൾ പരാജയപ്പെടുന്നത് ഇവിടെയാണ്. നിങ്ങളുടെ സ്റ്റാറ്റസ് പേജ്:

• നിങ്ങളുടെ ആപ്പിന്റെ അതേ സെർവറിലോ ഹോസ്റ്റിങ് അക്കൗണ്ടിലോ ആണെങ്കിൽ,
• അതേ ഡാറ്റാബേസിൽ നിന്ന് വായിക്കുന്നെങ്കിൽ,
• അതേ ഡൊമെയ്ൻ സെറ്റപ്പിലോ CDN കോൺഫിഗറേഷനിലോ ആണെങ്കിൽ,
• അല്ലെങ്കിൽ അതേ പൈപ്പ്‌ലൈൻ വഴി ഡിപ്ലോയ് ചെയ്യുന്നെങ്കിൽ,

പല ഔട്ടേജുകളിലും അത് ഒപ്പം നിശ്ചലമാകും, ആളുകൾക്ക് ഏറ്റവും വേണ്ട സമയത്ത്. പ്രായോഗിക നടപടികൾ:

• വേറിട്ട ഹോസ്റ്റിങ്. പ്രധാന ആപ്പിൽ നിന്ന് വേറെ പ്രോജക്റ്റോ ദാതാവോ.
• സ്വന്തം സബ്ഡൊമെയ്ൻ, ഉദാഹരണത്തിന് status.example.com, DNS-ൽ പ്രത്യേകമായി ചൂണ്ടിക്കാണിച്ചത്. ഡൊമെയ്‌നുകളും DNS-ഉം എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നത് കാണുക.
• സ്വന്തം ഡാറ്റ. സംഭവങ്ങൾ സ്റ്റാറ്റസ് പേജിന്റെ സ്വന്തം സ്റ്റോറേജിൽ ഇരിക്കണം, നിങ്ങളുടെ ആപ്പ് ഡാറ്റാബേസിൽ അല്ല.
• സ്റ്റാറ്റിക് ഫാൾബാക്ക്. ചില ടീമുകൾ പൊതു പേജ് സ്റ്റാറ്റിക് ആക്കി ഓരോ അപ്‌ഡേറ്റിലും വീണ്ടും നിർമ്മിക്കുന്നു, അതിനാൽ തകരാൻ ഏറെയൊന്നും ഉണ്ടാകില്ല.

മാനുവൽ അപ്‌ഡേറ്റുകളോ ഓട്ടോമേറ്റഡ് പരിശോധനകളോ

മാനുവൽ (ഇവിടെ തുടങ്ങുക)

അഡ്മിൻ പേജിൽ നിന്ന് നിങ്ങളുടെ ടീം കൈകൊണ്ട് സംഭവങ്ങൾ പോസ്റ്റ് ചെയ്യുകയും ഘടക സ്റ്റാറ്റസുകൾ മാറ്റുകയും ചെയ്യുന്നു. പ്രായോഗികമായി പല സ്റ്റാറ്റസ് പേജുകളും ഇങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത്, കാരണം “പേയ്‌മെന്റുകൾ ചില കാർഡ് തരങ്ങൾക്ക് മന്ദഗതിയിലാണ്” എന്നതുപോലുള്ള മനുഷ്യന്റെ വിലയിരുത്തൽ ഒരു ഓട്ടോമാറ്റിക് ചുവന്ന ഡോട്ടിനേക്കാൾ ഉപകാരപ്രദമാണ്.

പ്രശ്നങ്ങൾ വേഗം അറിയാൻ, ആപ്പ് ഓരോ മിനിറ്റിലോ മറ്റോ പരിശോധിക്കുന്ന ഒരു പുറത്തുള്ള അപ്‌ടൈം മോണിറ്റർ ഉപയോഗിക്കുക, അത് ഇമെയിൽ, SMS അല്ലെങ്കിൽ ചാറ്റ് വഴി അലേർട്ട് അയയ്ക്കട്ടെ. പല മോണിറ്ററിങ് സേവനങ്ങൾക്കും സൗജന്യ ടയറുകളുണ്ട്.

ഓട്ടോമേറ്റഡ്

ഓട്ടോമേഷൻ എന്നാൽ ഓരോ ഘടകവും ഒരു ഷെഡ്യൂളിൽ ആരെങ്കിലും പരിശോധിച്ച് അതിന്റെ സ്റ്റാറ്റസ് അപ്‌ഡേറ്റ് ചെയ്യുന്നു എന്നാണ്. അതിന് നിങ്ങളുടെ പ്രധാന ആപ്പിന്റെ ഇൻഫ്രാസ്ട്രക്ചറിന് പുറത്ത്, ഷെഡ്യൂളിൽ പ്രവർത്തിക്കുന്ന കോഡ് വേണം. രണ്ട് സാധാരണ രീതികൾ:

• ഒരു പുറത്തുള്ള മോണിറ്റർ പരിശോധന പരാജയപ്പെടുമ്പോഴോ വീണ്ടും ശരിയാകുമ്പോഴോ ഒരു വെബ്ഹുക്ക് വഴി സ്റ്റാറ്റസ് പേജിനെ വിളിക്കുന്നു, സ്റ്റാറ്റസ് പേജ് ഘടകം അപ്‌ഡേറ്റ് ചെയ്യുന്നു.
• സ്റ്റാറ്റസ് പേജിന്റെ സ്വന്തം ഹോസ്റ്റിങ്ങിലെ ഒരു ഷെഡ്യൂൾ ചെയ്ത ജോബ് ഓരോ ഘടകത്തിലും പിങ് ചെയ്ത് ഫലം രേഖപ്പെടുത്തുന്നു. ആശ്രയിക്കുന്നതിന് മുമ്പ് നിങ്ങളുടെ ഹോസ്റ്റിങ് ഷെഡ്യൂൾ ചെയ്ത ജോലികൾ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു എന്ന് പരിശോധിക്കുക. പശ്ചാത്തല ജോബുകൾ പ്രവർത്തിപ്പിക്കുന്നത് എന്ന ഗൈഡ് ഓപ്ഷനുകൾ വിശദീകരിക്കുന്നു.

ഓട്ടോമേറ്റഡ് മാറ്റങ്ങൾ ദുർബലമായ നെറ്റ്‌വർക്കിൽ മിന്നിമറയാം (up, down, up). സ്റ്റാറ്റസ് മാറ്റുന്നതിന് മുമ്പ് രണ്ടോ മൂന്നോ തവണ പരാജയം വേണമെന്ന് വെക്കുക, വലിയ തകരാർ പ്രഖ്യാപിക്കുന്നതിന് മുമ്പ് ഒരു മനുഷ്യൻ സ്ഥിരീകരിക്കട്ടെ.

സംഭവ അപ്‌ഡേറ്റുകൾ എഴുതുന്ന വിധം

• നേരത്തേ പോസ്റ്റ് ചെയ്യുക. “ലോഗിൻ പരാജയപ്പെടുന്നതിനെക്കുറിച്ചുള്ള റിപ്പോർട്ടുകൾ അന്വേഷിക്കുകയാണ്” എന്നത് ഒരു മണിക്കൂർ കഴിഞ്ഞുള്ള തികഞ്ഞ സന്ദേശത്തെക്കാൾ നല്ലതാണ് മിനിറ്റുകൾക്കുള്ളിൽ.
• ഉപയോക്താവ് എന്ത് അനുഭവിക്കുന്നു എന്ന് പറയുക, ആന്തരികമായി എന്ത് പൊട്ടി എന്നല്ല.
• അടുത്ത അപ്‌ഡേറ്റ് എപ്പോൾ എന്ന് വാക്ക് നൽകുക, അത് പാലിക്കുക.
• പരിഹരിച്ചു കഴിഞ്ഞാൽ ചെറിയ സംഗ്രഹത്തോടെ അവസാനിപ്പിക്കുക: എന്ത് സംഭവിച്ചു, എത്ര നേരം, എന്ത് മാറ്റുന്നു.

പ്രവർത്തിക്കുന്ന ഒരു ആദ്യ പ്രോംപ്റ്റ്

Parcelio എന്ന ആപ്പിനായി ഒരു സ്വതന്ത്ര സ്റ്റാറ്റസ് പേജ് നിർമ്മിക്കുക, status.parcelio.com-ൽ പ്രത്യേകമായി ഹോസ്റ്റ് ചെയ്യാൻ. ഘടകങ്ങൾ: Website, Tracking API, Notifications, Payments. ഓരോന്നിനും സ്റ്റാറ്റസ് Operational, Degraded performance, Partial outage, Major outage അല്ലെങ്കിൽ Under maintenance. പൊതു പേജ് മൊത്തത്തിലുള്ള ബാനർ കാണിക്കണം (ഏറ്റവും മോശം നിലവിലെ സ്റ്റാറ്റസ് ഉപയോഗിച്ച്), ഓരോ ഘടകവും അതിന്റെ സ്റ്റാറ്റസോടെ, സജീവമായ സംഭവങ്ങൾ സമയം രേഖപ്പെടുത്തിയ അപ്‌ഡേറ്റുകളോടെ പുതിയത് ആദ്യം, വരാനിരിക്കുന്ന അറ്റകുറ്റപ്പണി, മാസം തിരിച്ചുള്ള പഴയ സംഭവങ്ങളുടെ പട്ടിക. ഓരോ സംഭവത്തിനും സ്വന്തം പേജ്. പാസ്‌വേഡ് സംരക്ഷിത അഡ്മിൻ പേജ് ചേർക്കുക, അതിൽ സംഭവം സൃഷ്ടിക്കൽ (ശീർഷകം, ആഘാതം, ബാധിച്ച ഘടകങ്ങൾ), അപ്‌ഡേറ്റുകൾ പോസ്റ്റ് ചെയ്യൽ (സന്ദേശവും സ്റ്റാറ്റസും: Investigating, Identified, Monitoring, Resolved), ഘടക സ്റ്റാറ്റസ് മാറ്റൽ, അറ്റകുറ്റപ്പണി ഷെഡ്യൂൾ ചെയ്യൽ എന്നിവ. ഒരു പുറത്തുള്ള മോണിറ്ററിൽ നിന്ന് ഒരു രഹസ്യ ടോക്കൺ വഴി സംരക്ഷിച്ച POST /api/check-result എൻഡ്‌പോയിന്റ് ചേർക്കുക, അത് ഘടകത്തിന്റെ പേരും up/down-ഉം സ്വീകരിക്കണം, തുടർച്ചയായി മൂന്ന് down-കൾക്ക് ശേഷം മാത്രം ഘടകത്തെ Degraded ആയി അടയാളപ്പെടുത്തണം. എല്ലാം ഈ ആപ്പിന്റെ സ്വന്തം ഡാറ്റാബേസിൽ സൂക്ഷിക്കുക. ലളിതവും ശാന്തവുമായ ഡിസൈൻ, ഫോണുകളിൽ വേഗത്തിൽ ലോഡാകുന്നത്.

ബിൽഡ് ഘട്ടങ്ങൾ

1. പൊതു പേജും മാനുവൽ സംഭവങ്ങളുള്ള അഡ്മിനും. ഇത് മാത്രം ഒരു പ്രവർത്തിക്കുന്ന സ്റ്റാറ്റസ് പേജാണ്.
2. വേറിട്ട് ഹോസ്റ്റ് ചെയ്യുക, ഒരു സബ്ഡൊമെയ്‌ൻ അതിലേക്ക് ചൂണ്ടിക്കുക.
3. സംഭവ പേജുകളും ചരിത്രവും.
4. അറ്റകുറ്റപ്പണി ജാലകങ്ങൾ.
5. സബ്സ്ക്രിപ്ഷനുകൾ. ഡബിൾ ഓപ്റ്റ്-ഇൻ ഇമെയിൽ രജിസ്ട്രേഷനും പുതിയ സംഭവങ്ങളെയും അപ്‌ഡേറ്റുകളെയും കുറിച്ചുള്ള അറിയിപ്പുകളും. ഇമെയിലിന് ഒരു ദാതാവ് വേണം; ആപ്പിൽ നിന്ന് ഇമെയിൽ അയക്കുന്നത് എങ്ങനെ എന്ന് കാണുക.
6. മോണിറ്റർ വെബ്ഹുക്ക്, ഓട്ടോമാറ്റിക് സ്റ്റാറ്റസ് മാറ്റങ്ങൾ വേണമെങ്കിൽ.
7. ഒരു ഡ്രിൽ നടത്തുക. വ്യാജ സംഭവം സൃഷ്ടിക്കുക, അപ്‌ഡേറ്റുകൾ പോസ്റ്റ് ചെയ്യുക, പരിഹരിക്കുക, ഇമെയിലുകൾ പരിശോധിക്കുക, എന്നിട്ട് ഇല്ലാതാക്കുക.

സാധാരണ തെറ്റുകൾ

• ആപ്പിനൊപ്പം ഹോസ്റ്റ് ചെയ്യുന്നത്. ഏറ്റവും സാധാരണവും ഗുരുതരവുമായ തെറ്റ്.
• എപ്പോഴും “എല്ലാ സിസ്റ്റങ്ങളും പ്രവർത്തിക്കുന്നു” എന്ന് പറയുന്ന പേജ്. ഒരിക്കലും പ്രശ്നങ്ങൾ കാണിക്കാത്ത പേജിൽ ഉപയോക്താക്കൾ വിശ്വാസം നഷ്ടപ്പെടുത്തുന്നു.
• സമയമോ സമയമേഖലയോ ഇല്ലാത്തത്. സമയം എപ്പോഴും സമയമേഖലയോടു കൂടി കാണിക്കുക.
• അഡ്മിൻ പേജിന് പ്രധാന ആപ്പിന്റെ ലോഗിൻ ആശ്രയിക്കുന്നത്.
• അപ്‌ഡേറ്റുകൾക്കിടയിലെ നിശ്ശബ്ദത. “മാറ്റമില്ല, ഇപ്പോഴും പ്രവർത്തിക്കുന്നു” എന്നത് സാധുവായ ഒരു അപ്‌ഡേറ്റാണ്.
• ഓട്ടോമേറ്റഡ് സ്റ്റാറ്റസ് മിന്നിമറയുന്നത്. മാറ്റത്തിന് മുമ്പ് ആവർത്തിച്ചുള്ള പരാജയങ്ങൾ വേണം.

ഒരു ഹോസ്റ്റഡ് സ്റ്റാറ്റസ് പേജ് സേവനം മികച്ച തിരഞ്ഞെടുപ്പാകുമ്പോൾ

ഹോസ്റ്റഡ് സ്റ്റാറ്റസ് പേജ് സേവനങ്ങൾ സ്വതന്ത്ര ഇൻഫ്രാസ്ട്രക്ചറിൽ പ്രവർത്തിക്കുന്നു, ഇമെയിലും SMS വഴിയുള്ള സബ്സ്ക്രൈബർ അറിയിപ്പുകളും കൈകാര്യം ചെയ്യുന്നു, പലപ്പോഴും മോണിറ്ററിങ്ങും സംഭവ ഉപകരണങ്ങളുമായുള്ള സംയോജനവും ഉൾപ്പെടുന്നു. അപ്‌ടൈം നിങ്ങളുടെ ഉപഭോക്താക്കൾ പണം നൽകുന്നതിന്റെ ഭാഗമാണെങ്കിലോ തകരാറുകൾ റിപ്പോർട്ട് ചെയ്യാൻ കരാർ ബാധ്യതയുണ്ടെങ്കിലോ, ഒരു പ്രത്യേക സേവനം സാധാരണയായി വിലമതിക്കുന്നതാണ്. ചെറിയ ടീമുകൾക്ക് പലർക്കും സൗജന്യമോ കുറഞ്ഞ നിരക്കോ ഉള്ള ടയറുകളുണ്ട്, അതിനാൽ നിർമ്മിക്കുന്നതിന് മുമ്പ് പരിശോധിക്കുക.

ഡിസൈനും വാക്കുകളും പൂർണ്ണമായി നിയന്ത്രിക്കണമെങ്കിൽ, നിങ്ങളുടെ ആവശ്യങ്ങൾ ലളിതമാണെങ്കിൽ (കുറച്ച് ഘടകങ്ങൾ, മാനുവൽ അപ്‌ഡേറ്റുകൾ), അല്ലെങ്കിൽ മറ്റുള്ളവർക്കായി നിർമ്മിക്കുന്ന ഉൽപ്പന്നത്തിന്റെ ഭാഗമാണ് സ്റ്റാറ്റസ് പേജെങ്കിൽ, സ്വന്തമായി നിർമ്മിക്കുക.

Mythex ഉപയോഗിച്ച് നിർമ്മിക്കുന്നത്

Mythex-ൽ സ്റ്റാറ്റസ് പേജ് നിങ്ങളുടെ പ്രധാന ആപ്പിൽ നിന്ന് വേറിട്ട സ്വന്തം പ്രോജക്റ്റായി നിർമ്മിക്കാം. അങ്ങനെ അതിന് വേറിട്ട ഹോസ്റ്റിങ്ങും സ്വന്തം ഡാറ്റാബേസും ലഭിക്കും. ചാറ്റിൽ വിവരിക്കുക, ലൈവ് പ്രിവ്യൂവിൽ പരിശോധിക്കുക, തുടർന്ന് പ്രസിദ്ധീകരിച്ച് status.yourdomain.com പോലുള്ള ഒരു സബ്ഡൊമെയ്‌ൻ ബന്ധിപ്പിക്കുക (കസ്റ്റം ഡൊമെയ്‌നുകൾ Pro-യിലാണ്). ഓർക്കുക: പ്രസിദ്ധീകരിച്ച Mythex ആപ്പുകളും അവയുടെ ഡാറ്റാബേസുകളും ഉപയോഗമില്ലാതിരിക്കുമ്പോൾ ഉറങ്ങുകയും അടുത്ത സന്ദർശനത്തിൽ ഉണരുകയും ചെയ്യുന്നു, അതിനാൽ ശാന്തമായ സമയത്തിന് ശേഷമുള്ള ആദ്യ ലോഡ് അല്പം വൈകിയേക്കാം. ലളിതവും ഭാരം കുറഞ്ഞതുമായ പേജ് ഇത് സഹായിക്കും.

ഓട്ടോമേറ്റഡ് പരിശോധനകൾക്ക് Mythex ഷെഡ്യൂൾ ചെയ്ത ജോബുകൾ രേഖപ്പെടുത്തിയിട്ടില്ലാത്തതിനാൽ, സ്റ്റാറ്റസ് പേജിലെ ഒരു വെബ്ഹുക്ക് എൻഡ്‌പോയിന്റിനെ വിളിക്കുന്ന ഒരു പുറത്തുള്ള അപ്‌ടൈം മോണിറ്റർ ഉപയോഗിക്കുക (വെബ്ഹുക്ക് റെസിപ്പി കാണുക). സബ്സ്ക്രൈബർമാർക്കുള്ള ഇമെയിൽ അലേർട്ടുകൾ നിങ്ങളുടെ സ്വന്തം ദാതാവ് വഴി പോകുന്നു, കീ ഒരു പ്രോജക്റ്റ് സീക്രട്ടായി സൂക്ഷിക്കുന്നു (ഇമെയിൽ അയക്കൽ റെസിപ്പി).

ചോദ്യങ്ങൾ