Protected by Scarecrow

Because it’s out…standing in its field!

Good question!

Basically, Scarecrow is built for small business owners and independent web developers. Also, potentially, web hosting providers. If you have a team of dedicated IT staff, and developers using modern source control, you probably don’t need Scarecrow’s backups. If, though, you hire contractors/employees to work on your site? And, even if they’re using source control, you don’t have access to it? Or your peeps simply aren’t on call and available to restore your site in case of an emergency? You might want those backups handy. And, incidentally, VISIBLE TO YOU AT ANY TIME. We’re really proud of that visibility piece: we’ve seen no other backup system with this kind of transparency. Anywhere.

Truthfully, though, we think nearly every site would benefit from the distributed uptime checking and content monitoring. It’s not the same as getting a report from a web hosting provider’s datacenter. It’s a more holistic approach, checking from various geographical locations, while also monitoring content changes, that’s not so easy to build (and maintain!) for yourself.

Well, to start with: we absolutely think you should install a WordPress backup plugin! We use one ourselves. But there are some issues with trying to run Scarecrow itself that way, which is why we haven’t built one.

1. A lot of what Scarecrow does happens from multiple locations at once. So it can’t really be run just from your server. (Would it detect its own outages? How?)
2. Probably more important: there is an information management problem. If you can access your backups from your WordPress dashboard, and your site is hacked…well, the attacker may have access to them too.
3. Even if your site’s WordPress files have just been accidentally deleted, rather than hacked…well, how do you restore from that plugin’s backup? It may well be possible, but it takes some expertise.

If your site is functioning well enough that you do have access, though, a backup plugin can be very handy. There is almost certainly no harm in setting one up.

One thing we’ve noticed, though: a lot of plugins don’t actually back up your entire site. They may (for instance) back up everything except “the WordPress core.” This makes backups smaller, of course, but there’s also a potential problem. What if you don’t know which version of WordPress you were running? How do you get the right files back, without access to your WP Dashboard?

Again, a competent developer or site administrator can probably solve these issues for you. But, since Scarecrow isn’t a WP plugin, it helps you take care of the problem yourself. That’s kind of our jam.

There are actually FOUR different statuses, not simply up/down, which is something unique to Scarecrow:

• Site UP: Straightforward! But, to be clear, this means that your site is responding normally, AND that there were no DNS issues (DNS is required for users to actually find your site’s IP address), AND that there were no certificate issues (current certificates are required for secure browsing). All of this is checked from multiple locatiions, which leads us to…
• Disputed outages: This could mean any of a lot of things. The server might be down, there could be a DNS issue, or there might be a certificate issue, from one or more locations. BUT, and this is the interesting part: everything was fine from at least one location! Scarecrow identifies exactly what is going on and sends a detailed notification. You can also click the ‘site down’ status in your dashboard to see the notification details and suggested fixes.
• Confirmed outages: This means that all monitoring locations agreed a site was down. Again, you can check either an email notification or the dashboard status link for further information and ways to recover.
• Content down: Everything else seemed fine, but the content Scarecrow was looking for was not found on your site. This might mean Scarecrow just needs to be updated, or it could be a more serious issue.

Considering a change of hosting provider? Here’s how to make it happen, assuming you are currently subscribed to either the Business or Agency tier, and you have a recent backup (or a historical one, if you prefer):

1. From your dashboard, go to “Configure site” and turn off file monitoring and database backups. Save the site.
2. Go back to configure the site again. Enter the new address (might be just an IP address if you have not yet updated DNS settings) and new credentials.
   1. If you are migrating a WordPress site, the simplest thing to do is to pre-create a NEW wordpress site at your new location. This will allow you to restore your old database into its new home later. We mention this because hosting providers often offer one-click installs; this makes it easy.
   2. You will also need to be sure you have write permissions to the new server’s filesystem.
   3. If the site’s web root is different (maybe ‘www’ vs. ‘public_html’, or something similar), you’ll need to enter the new root also.
3. Click the ‘Test’ button from your files tab in the configure site wizard. If all goes well (it will auto-detect WordPress sites and database credentials if present, assuming you’re pointing Scarecrow at the site root).
4. Once that’s working, go to the data tab and configure/test your database credentials if needed.
5. Save the site.
6. Initiate a Restore from the dashboard, choosing either files, database, or both.
7. Generally within a few minutes, but sometimes longer (could be hours in some circumstances), you’ll get a notification that the restore has completed. Note: the Restore will automatically update your WordPress database credentials, and database name, in your configuration if they need it.
8. If all went well? Great! If you hadn’t done this already, you can now point your DNS to the new location. Optionally, you can also update Scarecrow with the correct hostname.
9. Done! (but don’t forget to re-enable file/database monitoring and backup, so you’ll be ready next time!

Well, generally they happen right after we get a snapshot of your site with changes detected. OR, for a new site, this is automatic already. But there’s a trick for backing up a pre-existing site as soon as possible: turn monitoring OFF for your files. Save the site. Then turn it back on, save the site again, and the next snapshot should happen right away. For a database backup, the exact same trick works. Disable, save, re-enable, save.

Okay, truthfully, we’re trolling a little bit here. We do not charge by page impressions OR by the number of checks per month…but some feature-limited competitors do! With very interesting pricing, but let’s leave it at that….

So let’s do some math. Assuming you are a Basic tier user, you have only one site. Let’s say it is checked from five locations (the number varies, but that’s in the ballpark). And you have it set to check every 5 minutes.

5 checkers, every 5 minutes, works out to an average of one per minute (though of course in reality they check in bursts of 5). 60 minutes in an hour, 24 hours in a day, we’ll say 30 days in a month. You get 43,200 page impressions per month. BUT, if you specify website content…and you can do that for two separate pages/locations on your site…it’s 86,400 per site per month.

NOTE: Business tier? You get four times that number, so half the price per site. Agency tier? Well, you know, 86,400 per site.

But frankly? “Page impressions” is kind of a silly metric. At least in our opinion. Seems like it’s a slightly misused term in this context, also. Plus? As far as we know, nobody else is checking for specific content, and DNS (multiple services checked per location), AND certificate monitoring from multiple locations, as well as basic up/down status. Just saying.

And, um…if you’re also having Scarecrow check your site, hourly perhaps, for changes to actual files? We don’t know anybody who’s doing that either. Food for thought, eh? Gotta say, though, it seems to us that all this stuff should be standard operating procedure by now. How come it isn’t?

Because we don’t even know what that means! Page loads from where? When? It matters.

If we were ALWAYS checking from the same location, okay, we could watch for trends over time. We couldn’t really know what good or bad meant without checking all sites from that same location, and what if the sites are actually all over the world? Which of course they are. Hmm. Plus, what are we going to do, show data for all sites to everybody? No. Total privacy violation. Even just providing “averages”, however we calculated that, would be revealing too much for our comfort. Kind of a strong pro-privacy stance around here. We do not willingly share user data outside what’s needed for billing (see our privacy policy).

In theory, we could measure ping time, and compare that to the total time it took to see the full page content. But so what? To do this properly, we’d really want to set up a huge network of distributed checking locations so we could always be measuring from someplace “near” a website’s server. Never mind that ping time changes a lot, and there’s no guarantee that so-called “page load” behavior and ping time would actually be traveling companions. Either might be much slower, or faster, than the other. At any time.

Doable in theory. Or measuring ping time and doing the math is actually possible with our current setup. But then what? We’d have multiple answers from different locations. Which answers would be meaningful, and which wouldn’t? Frankly…variations in “page load” happen all the time, and we don’t see how single-location monitoring tells you much more than just refreshing a page in your browser does.

To put it another way: we don’t think this is an actually useful feature. Or not without a lot of infrastructure and tracking logic, anyway. And still, at the end of the day…more useful than refreshing the browser? Probably not. Just our opinion. Hey, if you want to get actual worst-case page load time? Hit CTRL/CMD + F5 in your browser. It forces a full refresh, so it stresses the server and network a bit more. So there you go…?

For a forgotten password, this works like many other sites, but we are a disaster recovery service and have to be a bit more careful. You’ll need your username. You can click the “Forgot Password” link, and enter it. You will receive a one-time password (easiest to copy this for later pasting) for the reset, and we’ll send you a link to reset. The reset link will take you to a page asking for the one-time password. Paste the password in there, and you can then reset your account’s password. The main point here is that if somebody gains access to your email account, that is NOT all they need to reset your password. They would need access to your email, your username, and the one-time password.

A forgotten username takes a bit more interaction. Shoot us an email from your “primary email” account set up in our system. Then we can do one of two things:

1. If you are the business owner or work for a business whose site is hosted, and we can reach you via contact information posted on one of your sites, we’ll either call or email to verify ownership. Or use a contact form. Whatever works.
2. If you are an IT person who manages the sites, just add a TXT record to one of the domains’ DNS records containing “PROTECTEDBYSCARECROW” and we’ll verify that way. In fact, a single email with the TXT record in place, from the proper email address, will suffice.

Either way, we’ll then give you your username and you can proceed with a standard password reset if you need to. This is not an automated process. It does require us to personally respond, so it may take up to a day before we can get to it. We don’t mean to be difficult here–but given that the “disaster” in disaster recovery is fairly often caused by compromised user credentials in the first place, we really do have to be a bit persnickety in spots.

If you’ve forgotten which email address you used, well, log in and check “account settings.” If you’ve somehow deleted all of our notifications and forgotten which address you used…listen, we don’t judge…but if you also forgot your username, see the bit about a forgotten username above. We’ll probably need both (a) and (b) to proceed, but we’ll figure something out. Or of course you could just send an email from each address you MIGHT have used. That will probably make at least one of us laugh, but it should work out okay in the end.

It depends! We actually change our minds from time to time and add/remove a location, and move things around as needed.. Also, when you configure your site you have the option to allow monitoring from USA-only, non-USA-only, or all locations. Some folks have geolocation blocking turned on, and they need to exclude certain countries/regions. If you need more granular control, let us know.

Current USA locations: Oregon, Los Angeles, San Antonio, Virginia, New Jersey, Chicago

Current non-USA locations: Bangalore, Germany, Johannesburg

If you need coverage (from) somewhere else, let us know and we’ll consider it. We’re somewhat limited by available datacenters, but we’re open to suggestions!