A cautionary tale: I was using this script for a while. Then Google Docs had some sort of freakout, and began sending me hundreds of "your site is down" emails, even after I tried to terminate the script and even deleted the document from my Google Drive. A few days later, the script finally terminated and the messages stopped.
AppsScript in general should not be used for production purposes, or anything that depends on timely and consistently responses. Even Google will tell you this (and they provide no SLA on AppsScript for enterprise customers, either). That said, it's still a lot of fun to play with, and there are all sorts of useful things you can do with scripts anyway.
1. Reliance on Google Docs' uptime. While any monitoring service will in theory present the same problem, you're putting all your eggs in one basket.
2. It's just the wrong tool for the job. Install and learn Nagios or Zabbix or what-have-you. If you're worried about uptime, get a couple VPSes from different providers and run your monitors from both.
There's nothing utterly horrifying about it technically, but I just can't imagine how one comes up with this answer to the question of monitoring services.
Ok, but as you pointed out, #1 is just as bad as using any other single provider (which isn't implied or suggested anywhere here). I disagree with #2. The results are pretty nice, and they're accessible through Google Docs, which is great for sharing with co-workers who aren't in IT.
For what it's worth, Google Docs isn't our only monitoring system. We use Munin as our primary monitoring tool, but this is a nice addition to that.
Funny you mention this because we use Nagios to monitor the availability of Google apps (Drive & Gmail mostly) and I get a false positive about once a fortnight. It's proven much more helpful to just monitor HN/Reddit or Twitter to figure out when there's an outage.
Do you make API calls, or just grab web pages? I've noticed the Google APIs seem to occasionally return errors for no apparent reason. You could try double-trying in your Nagios check.
It's also complicated by Google's infrastructure — services are scattered across many, many servers, and Google's outages tend to be on some subset of services and/or servers. Your Nagios checks are probably not always checking the same endpoint as users connecting.
You do realize that this is not a feature of Docs and no "product manager" had anything to do with it, right? Somebody wrote an app script that uses the URLFetchApp.fetch function.
By the way, Microsoft Office has, at various times, contained a flight simulator, a pinball game, and a first-person shooter.
I've used it and it is pretty mediocre or at times just inaccurate. I get so many false alerts from Google about the site being down that I've turned it off.
As another comment puts it, it's just the wrong tool for the job.
I've used a modified version of the script for over a year now and was able to determine unreliable sites with it. Of course there can be temporary server issues and when you try to access the site it works again.
The script I wrote checks multiple sites in one go and sends one mail per script execution, if there are errors. I found that more manageable, the code for it is on GitHub
https://github.com/yaph/sitemonitor
I just set this up. Works great! I recommend you run it once from the Run menu to make sure you entered a domain name correctly. You can comment out this line to get an email every time it runs (good for testing):
I highly recommend http://www.uptimerobot.com which is a free tool. You can monitor up to 50 sites with 5 min intervals. Very useful email notifications specifying how much time your site was unavailable.
Why not just use Pingdom which is designed for that?
One thing Docs is good for though is building custom dashboards on a $0 budget. We've got one at https://starthq.com that shows our key metrics and graphs cohorts for the last few weeks.
We created a simple API which gives us data ranges such as
- /:start/:end - number of users registered within date range
- /:start/:end/active - number of users registered within date range who were active within last week
etc. etc.
Then it's pretty straightforward to use ImportData & CONCATENATE, as well as fill down to create a matrix of cohorts, which can in turn be graphed.
In general it's best to pull in the raw data with ImportData and then calculate percentages and such in the spreadsheet. The latter are updated when the cells they reference refresh.
Docs refreshes ImportData sources once every hour, caching them in between, so the load on the server and DB is minimal and you end up with more or less current stats.
This is awesome, in the sense that I am in awe that google lets you do this. Could you create a shareable doc to create a google powered DDOS of a site? Hypothetically, of course.
Interesting read. Also, good on Amazon for the P.S at the end: "Amazon was nice enough to refund the bandwidth charges [...] as they considered this activity accidental and not intentional."
In my experience all HTTP requests made from Google Docs functions and scripts are cached for at least a few minutes. There are workarounds to that but I would guess they do throttling at an IP and domain level as well (being that they know a thing or two about crawling the web).
I'm pleased to see people showing off what you can do with Google docs. I think most people (and even most developers) totally underestimate what's possible with Google Apps Script.
A great example of what is possible using Spreadsheets to do live dashboards and analysis of site data. If you use Heroku you can pump data directly from Heroku Dataclips into a Google spreadsheet using a live CSV URL and then analyse, munge and display it however you like.
Apps Script can both consume send data to other web services so coupled with Heroku Dataclips or Chartio.com it's super powerful. It's a great way to skip a lot of UI work or even for someone with business savvy but no official programming skill to get directly into their database and spelunk around.
This is pretty cool. The google calendar event to create texts seems like a hack though (even more-so than the rest of it). Is there any reason this couldn't just use the SMS gateways that pretty much every carrier offers?
I have tested this in the past, and a few clients on the service I launched last year (https://servercheck.in/) have also reported the same: Google Docs is unreliable at best. Besides false positives, there were at least two or three outages (sometimes for an hour or more) unreported.
Google Docs is not meant to be a status monitoring tool. Use the right tool for the job; there are plenty of free and cheap alternatives that do things much better, are more reliable, and save you setup and maintenance time.
Depending on Google Spreadsheet for uptime monitoring is nothing more than just a fun hack. I'm surprised that some people here are taking it so seriously. If you're using a script like this, then I hope it's just to keep those single dynos from falling asleep :)
It's also subject to Google Docs availability, my script sometimes fails to run with only a "We're sorry, a server error occurred. Please wait a bit and try again." email notification.
I've hacked something similar with ethercalc (npm install ethercalc) and you should too because you never know when google will sunset your favorite feature..
Interesting spreadsheet hack, but it's just looking for a 200 response. I use Pingdom, which allows you to look for specific content in the response, even on the free plan. It's a better guarantee that the page rendered successfully end-to-end.
I would love to use this, but the app wants access to all of my spreadsheets at any time. It looks like I'll need to set up a dummy Google account first.
If you're using it to check your own site, presumably you know what the target of any 301 is beforehand, and can aim at that URL in the first place. Even if you're using a proper monitoring system, why force your server to handle twice the number of requests than it needs to?
It still blows me away when I go to a root domain and get redirected to example.com/home or something similar. Or sites that append slashes to all URLs, but the content links to the slash-less copy, forcing every click to hit the server twice. Gah!
um. i'm curious why using this results in a high false positive rate. google docs has dodgy connectivity??? would checking if yahoo.com is up first, before checking each url, reduce the false positives?
I assume because, AFAIK, SMS notifications are handled by Google Calendar. So to give you the warning it makes an event with an SMS reminder that contains the warning as its topic
