4 ms·

And that's why you should always use a different domain for your status pages! GitHub does it well, for instance: https://www.githubstatus.com/ https://www.git

by kjaer 6y ago

And that's why you should always use a different domain for your status pages! GitHub does it well, for instance: https://www.githubstatus.com/ https://www.githubstatus.com/

ThePadawan 6y ago
I smell an ironic business opportunity in the ".status " TLD...
- yawnxyz 6y ago
  that's really clever... too bad I can't afford a TLD
colinbartlett 6y ago
I wrote a blog post about this once[1] because I was totally shocked how few people actually use a separate domain for their status page. It's like < 0.5% and I'll never understand why. 1. https://statusgator.com/blog/2020/04/21/your-status-page-deserves-its-own-domain/ https://statusgator.com/blog/2020/04/21/your-status-page-des...
- ajonit 6y ago
  >>But you can’t use two completely different DNS providers for your status page and your primary page unless you are using a distinct domain. You can.
  - zinekeller 6y ago
    > >>But you can’t use two completely different DNS providers for your status page and your primary page unless you are using a distinct domain. > You can. Depends on who's who though. Yes, it can be separate if they were different non-apex (AKA like www.google.com and mail.google.com) domains and apex domains (like google.com) can use at least two (depending on your registry) different DNS servers. However, by design there is an implication that your apex DNS servers are synchronised (or reasonably so). So for example, one of your provider have malfunctioned and instead of just pulling it offline it answered your requests with an IP address you don't control (let's say 198.51.100.17, which is not a routable address) with a exceedingly long TTL (say a week). If a client-side DNS resolver followed it through the heart, it will not allow anything to reach the intended server, even the functions server for non-apex domains. Plus, registry issues (there is only one registry in the end) and if they messed up, the website is going down (unless they are prudent) etc.

by kjaer 6y ago

And that's why you should always use a different domain for your status pages! GitHub does it well, for instance: https://www.githubstatus.com/ https://www.githubstatus.com/

ThePadawan 6y ago

I smell an ironic business opportunity in the ".status " TLD...

yawnxyz 6y ago
that's really clever... too bad I can't afford a TLD

colinbartlett 6y ago

I wrote a blog post about this once[1] because I was totally shocked how few people actually use a separate domain for their status page. It's like < 0.5% and I'll never understand why. 1. https://statusgator.com/blog/2020/04/21/your-status-page-deserves-its-own-domain/ https://statusgator.com/blog/2020/04/21/your-status-page-des...

ajonit 6y ago
>>But you can’t use two completely different DNS providers for your status page and your primary page unless you are using a distinct domain. You can.
- zinekeller 6y ago
  > >>But you can’t use two completely different DNS providers for your status page and your primary page unless you are using a distinct domain. > You can. Depends on who's who though. Yes, it can be separate if they were different non-apex (AKA like www.google.com and mail.google.com) domains and apex domains (like google.com) can use at least two (depending on your registry) different DNS servers. However, by design there is an implication that your apex DNS servers are synchronised (or reasonably so). So for example, one of your provider have malfunctioned and instead of just pulling it offline it answered your requests with an IP address you don't control (let's say 198.51.100.17, which is not a routable address) with a exceedingly long TTL (say a week). If a client-side DNS resolver followed it through the heart, it will not allow anything to reach the intended server, even the functions server for non-apex domains. Plus, registry issues (there is only one registry in the end) and if they messed up, the website is going down (unless they are prudent) etc.