Let’s paint a likely scenario: it’s the night before a huge online sale you’re having and you’re the head of your ecommerce company’s IT Department, responsible for making sure your storefront is up and performing fast. Your significant other is sound asleep next to you without a care in the world, but you can’t relax. What if something happens? What if we get too much traffic? What if….?
You also would be ripping some Z’s if you had set up HTTP monitoring with your own custom parameters, sparking a failover to your disaster recovery site if something happened. Consider it your managed DNS version of crime fighting super monitors, keeping the streets safe from downtime.
So how does it work?
We believe in redundancy and performance. For the health monitoring on all our services, three of our closest points of presence (currently 17 around the world) send a request to your webserver and monitor the response based on the parameters you define.
If two out of the three “agents of uptime” detect an outage, we then failover to your backup server. (Bam! Whack!) Take that, false positives!
That’s not all. Remember those custom parameters I mentioned way back at the beginning? Well, get ready to live. By defining more parameters, you can mimic a full HTTP request and response, replicating your real users’ experiences.
Let’s dig in to what you can define:
- Interval: This allows YOU to determine how often you want this check to occur. It can range anywhere from one, five, ten, or fifteen minutes. Choices are everything and we let you choose what fits your company’s needs.
- Retries: Remember the false positives that the super monitors of steel already crushed before? This allows you to define the number of times you want us to try your webserver with a 10 second interval once a failover event is detected.
- Port: Just in case your ISP decides to close Port 80 on you or some other roadblock, we give you the ability to enter another port for us to send the check over here.
- Path: Identify the specific file/folder the check should be sent to. Want to check example.com/wegotthestuffyouwanttobuy? Enter the subfolder here.
- Expected Data: Yes, your users are likely human and this allows you to define the actual words that should be contained in the body of the webpage your webserver is returning to the user. You can even define something that’s hidden in the source of the page that a user can’t see.
- Host: If you have an HTTP redirect from example.com to www.example.com, you can define a different host for the monitors to check. Another excellent use case is to test a real hostname of a website from a fake hostname in your DNS (omg-fake-failover.example.com testing www.example.com). Flexibility is key.
- Header: Your users are likely human, but their computers processing the HTTP request are not and thus need the operating parameters of the HTTP transaction. Define the components of the message header if necessary here. A common example is server-required user-agent definitions for HTTPS transactions.
That’s ensuring the right kind of uptime.
Now that you know what your users are getting returned to them, you can get some sleep. You’ve got a big day tomorrow. The super monitors of steel strike again. No kryptonite here!