Very good questions, and ones I had to think about quite a bit while building my MVP:
15 minute interval: I had to make sure the site was scalable in the beginning. My early testing data tells me that, for my target audience (as you say, probably not larger businesses at this point), 15 minutes is a good interval—it's better than most free services, but not so frequent as to incur extra expense on my end for bandwidth and database growth.
One location only: This is a compromise I have made for now—I have built the service in a way that I'll be able to add another node or two for the back-end checks once I get enough users. But for now, if the main server is down (hasn't happened yet, in four months of testing, but it will...), I only have a small bit of contingency, and don't have a hot backup.
Re-check for failure: Yes; if Server Check.in notices a site is down on more than 50% of node checks (once I have more than one node), it will check the site once more after a minute before sending a down notice.
API access: I don't have it yet, but I'm going to be building it (everything I've done on the site already has API data structures in place—I just don't have any of the interface or any kind of authentication system in place). I'm working on a mobile app that will be free for users, and will need the API up and running before I can launch it.
From my experience, going from one to multiple monitoring nodes gets way more complicated than expected; make sure you have your timestamps across the nodes right, especially when you decide to go down with the interval to 1 minute or less.
Also, investing time in a testing setup where all scenarios can be tested paid off greatly. Having scripts covering all edge cases lets you sleep better when you have paying customers :-)
Thanks, and am in full agreement with both the difficulty of multi-node sync and testing. I have test coverage of most of the front-end, but I need to do more with the backend to make sure what is working great now works great a year from now.
15 minute interval: I had to make sure the site was scalable in the beginning. My early testing data tells me that, for my target audience (as you say, probably not larger businesses at this point), 15 minutes is a good interval—it's better than most free services, but not so frequent as to incur extra expense on my end for bandwidth and database growth.
One location only: This is a compromise I have made for now—I have built the service in a way that I'll be able to add another node or two for the back-end checks once I get enough users. But for now, if the main server is down (hasn't happened yet, in four months of testing, but it will...), I only have a small bit of contingency, and don't have a hot backup.
Re-check for failure: Yes; if Server Check.in notices a site is down on more than 50% of node checks (once I have more than one node), it will check the site once more after a minute before sending a down notice.
API access: I don't have it yet, but I'm going to be building it (everything I've done on the site already has API data structures in place—I just don't have any of the interface or any kind of authentication system in place). I'm working on a mobile app that will be free for users, and will need the API up and running before I can launch it.