We have an Adxstduio Portals v7 site that’s been causing us grief recently by getting stuck in an error state. The error state is easily resolved by clearing the cache, but this solution required manual intervention. Since the site is currently being upgraded to v8, we didn’t want to invest too much into finding the root cause – it was easier to just kill the cache when the site went down. But what was even easier was using Microsoft Flow and Uptime Robot to do the job for us.
We are big believers in site monitoring scripts – that is, a processes that checks a website periodically to make sure that it’s running normally. Unless you want to spend your time manually checking websites, they are great for letting you know if there are any issues, usually before a client even notices.
We’ve been using Uptime Robot for years. It’s simple to use and the free plan provides us with everything we need. It checks our client’s sites every 5 minutes, and if the site is down (if the response code is in the 400s or 500s) it can notify us via email and/or text message. You can also get fancier, by having the script look for a particular word, or the absence of a word, which is helpful if you have custom error pages that may return 200 status codes even when server errors occur.
In our case, we have all of our notifications sent via email to a shared support inbox, plus I get a text message.
The trouble we had was one client’s site would get stuck in an error state, sometimes multiple times per week. All we had to do was use the Kill Cache browser shortcut to get the site back up and running. However, since we’re currently in the process of upgrading them to the xRM Portals Community Edition, it didn’t make sense to spend a bunch of time investigating. But it did become a bit of a pain, and we didn’t want any prolonged outages if we missed a notification from Uptime Robot.
As you might expect, the email notifications that Uptime Robot sends are in a predictable format, which makes them perfect as an input to a Flow.
We used the When a new email arrives in a shared mailbox step (currently listed as in Preview) to trigger our flow. By including a Subject Filter equal to Monitor is DOWN: [MONITOR NAME], we were able to kick things off.
The next (and final!) step was to trigger the cache invalidation on our Portal. In this particular case, the cache invalidation handler (available at /Cache.axd) did not require authentication, so we didn’t have to worry about providing a username and password. We simply setup an HTTP Flow step with the following settings to send a request to the portal to invalidate its cache:
Now, when the site goes down, we get a message notifying us, and then minutes later, we get another message that tells us it’s back up. No more manual intervention required!
[…] post Using Microsoft Flow and Uptime Robot to Keep Adxstudio Portals Site Alive appeared first on Engineered […]