I've been using a free Pingdom account for a few years to get notifications when different websites were down. I wanted to get SMS notifications (in addition to email notifications), but the only way to do that (besides paying for a relatively expensive full account) was to add my cell number's SMS gateway address [phone number]@sms.att.net. I did that for a while, but wasn't satisfied with the experience (each notification comes from a different number, and is formatted strange). Also, while Pingdom covers every scenario imaginable, I just wanted to be able to make sure a few web pages were responding with a 200 OK, and my main servers were online.
After surveying the landscape of monitoring services, I noticed few did everything I wanted (notify me when my site is down, allow me to track a few sites, and send me text messages and emails) for less than $30-50/year. So, after doing a little research, I found I could offer the exact service I wanted for around $10-15/year (that's $1.00-1.50/month) if I did it on my own. And so I built Server Check.in.
Server Check.in uses Stripe for payment acceptance (leagues beyond PayPal in terms of UX and DX), Twilio for SMS notifications ($0.01/message is bearable, and means there's room for a small profit), and Drupal on a LAMP server. Drush ('DRUpal SHell') handles most of the back-end (processing queues, checking servers, etc.), and I built the responsive HTML5 theme using Zen. Three custom modules drive the site, and integrate the notification and payment services. I have a post that explains the architecture with more detail here: http://www.lifeisaprayer.com/blog/2012/server-checkin-websit...
I stuck with what I know (a LAMP stack) for this project, though I'm dabbling in Python and Node.js to see if I might want to move more of the backend services away from PHP and shell scripting. I hope the service will grow large enough that I'll need to expand horizontally, but right now there's plenty of room for an initial batch of users.
Also, check out the 404 page; I made a little easter egg that I hope I can make more interesting over time :)
I'd appreciate any feedback; especially any ideas for improvement, or ways I could make it a more enticing service for other developers.
If you'd like to sign up, here's a coupon code for 20% off your first year: hn_twenty_off
I currently use http://www.uptimerobot.com which is free, up to 50 sites, does checks every 5 minutes, has an API, and alerts by email, SMS, Twitter, RSS or push notifications for iPhone/iPad. I notice you offer latency stats which is nice. Are there any other differences that would sway myself or others to pay for your service vs. their free service?
Server Check.in will never have ads, and the privacy policy (https://servercheck.in/privacy) is pretty clear cut. The revenue comes from the users, so the service is 100% user-focused.
I noticed their service when building Server Check.in, but didn't create an account for testing, so can't say anything with 100% certainty. However...
- SMS is not free (unless they're using email-to-SMS gateways), so I'm not sure how they're supporting that, unless they have alternative revenue streams.
- Database bandwidth/storage for more than a few servers costs money—I've calculated at least a few MB/month/server, meaning the data storage and access is a real cost I have to find money for.
Finally, they mention on their about page that they won't do paid until at least Feb. 2013, so I don't know if they'll still be free after that anyways :-/
(This is not to say I don't think their service is bad or anything—I think it looks like a worthy alternative... it's just not what I wanted to use, otherwise, I wouldn't have built Server Check.in.)
Sure thing! I considered using email-to-SMS and lowering the cost to < $1.00/month, but didn't want to make that compromise.
I do have to limit the SMS messages to 50/month (600/year) maximum at this point (see: https://servercheck.in/sms), until I can better track people's usage patterns and make sure I don't get hammered with larger fees than I'm taking in. That limit will hopefully be lifted at some point.
Love it, very nice and simple - best of luck. With a site that simple, A/B testing is going to be much easier and more productive I think.
My feedback would be:
- I'd be happy to pay twice as much if you offered 1-minute monitoring (or even 2 or 5, worth testing those)
- If you're going after small businesses (for whom a 15-min interval is sufficient) then I'd go all out on the branding for that. "Uptime monitoring for the rest of us" kind of thing. Make the 'no bells and whistles' approach the primary feature! That's how https://openexchangerates.org became popular (it's the simplest API to work with, and accurate enough for most users, while not needing to be the absolute gold-standard...)
Very helpful feedback; a couple people have told me they'd like to see a higher-tier plan with the option of more servers, and more frequent checks. I'm definitely considering this, but need to do more testing on my end to make sure I can scale well while adding on these kinds of features.
My #1 goal is to only have the features necessary to make the service great for most individuals/small developers. I think a better plan would work well with that.
What do you guys think is the best price/feature ratio for that kind of service? I can't find any detailed feature listing on the website, but it seems you can't offer much for ~$1 a month.
Do you think 15 minute interval is enough? I assume the checks are made from one network location only (can't find details on the about page), would anyone be confident of the results with such setup? Is there any re-check in case of failure? API access? Etc.
I think this service might be popular with amateur bloggers/website owners. I don't think it would satisfy businesses that consider downtime a profit loss. I think they might be looking for a bit more advanced solution.
P.S.
I'm a bit biased here. Since I started my own website monitoring project it seems that everyone else and their dog are also running one... :-(
Good news is that my service becomes recognizable in Poland and I'll be launching it for the rest of the world soon :-) Hope to get some feedback here when that happens.
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.
Some features I'd love, not exactly particular to you but for monitoring in general, since you have a few competitors posting here, too.
a) Give you my company's status twitter feed credentials; when a genuine problem is discovered, post for me that a problem was detected. Post again once the problem appears to be resolved.
b) Let me point a domain at you and give me a public status dashboard. Publish various stats and statuses (based on options I pick; don't make me publish load time, but if I want to I could publish trended load time data) and allow me to post messages both via your web control panel as well as SMS. Don't bother setting up infrastructure for me to register my domain through you. Most companies already have their preferred domain name provider. Don't create extra work for yourself; just give me the IP addresses to point via DNS.
c) Regularly sent emails detailing status over the past week and month. Do not embed it inside a PDF attachment to the email. Once I set up the service, I hope I never have to go back to your site because my sites never go down. However, if I get an email stating the uptime % this week vs. last week, or the response time average of this month vs. last month, that prompts action on my part. Do not over-email!
d) When you send me an alert that my site is down, please include enough info. What site? What service (HTTP/HTTPS/whatever else)? Why did it fail, did it 500? 404? Time out? I've looked at a lot of monitoring solutions and many of their SMS notices just say "Haaay. Yer shit is down. kthx" which is very unhelpful when your SMS wakes me up at 4am.
e) When sending SMS, make sure it comes from a single predictable number. This way I can assign it its own tone on my phone. Bonus points if you tell me the number up front, or send me a confirmation SMS.
f) If you're offering "page speed" type metrics, make sure I (the customer) know where you're measuring from. If all of my customers are Canadian, and you're measuring from Australia... if it takes an extra 100ms for the page to load, I'd like to know before you bombard me with SMS.
Edit! g) Make sure it's clear in your reports/site what time zone I'm looking at. A lot of the smaller sites get this wrong. Either show it UTC or let me pick what TZ I'm in. Do not do silly things like trying to guess my timezone based on IP address.
Just a couple quick responses, at least as far as Server Check.in is concerned:
a, b, c are currently not on my radar (since I don't want to spread myself thin :).
d - I have the site name, but not the status, at this time. That's a good point (of course, SMS messages being limited to 160 characters makes this a bit tougher than it should be for SMS).
e - Server Check.in uses one predictable number (no email-to-sms from a random number) - see https://servercheck.in/sms
f - For now, we're just measuring from the east coast, USA, but I'm planning on averaging results from a node there, a node in Dallas, TX, a node in Seattle, WA, and a node somewhere in the EU within the next year or so.
g - Since I'm using Drupal for the site's front-end, this is incredibly easy—Drupal tries to autodetect your TZ on signup, and you can change it in your account settings. All times should be displayed in your TZ. (If they aren't, let me know and I'll fix it!)
Using Google's AppEngine, how many sites could you monitor how often before you would hit the billing threshold?
I see they now offer Go in addition to Python and Java. I'd probably go with Python because it's so easy. Although, it might be fun to have a go at Go.
I haven't done anything with Go yet (barely even looked through docs), but it would be an interesting project to at least build a small part of it there and test.
Judging by Google App Cloud pricing, I'd probably be able to get somewhere between 200-300 users on their free tier. The biggest data hog is the database ops and storage; right now I'm archiving all historical data for each server.
I'm more comfortable with AWS at this point, though, so I'd probably stick with just moving one or two services to that before considering App Engine. I just don't have the time (right now) to try to work with more than one or two systems.
Just realized I had KeepAlive on; some people were waiting a bit for a connection—sorry about that!
Also noticed a lot of people are trying to use the 404 page a bit more as a terminal session—I had plans on making that work a bit better, but didn't have time to finish all of it and keep it secure. Soon...
I use watchmouse, there are tones of other companies doing it. How is your service better than others? This morning I signed up a free account with http://www.verelo.com/ to check their features.
Pricing: $1.25/month ($15/year) compares pretty favorably with most services I've seen (most start at $5/month or $50/year).
SMS: Most services either charge extra (~$0.20/message on average, or add a service fee for SMS notifications. Or, they only offer email-to-SMS, so you're not getting properly-formatted messages from a real phone number.
Simplicity: I'm trying to make this service as simple as possible to use. If you need a ton of special features, there are a lot of sites that give that to you—however, I just want to add servers to monitor, add my contact information, and forget about things until one of my servers goes down. Which hopefully never happens :)
After surveying the landscape of monitoring services, I noticed few did everything I wanted (notify me when my site is down, allow me to track a few sites, and send me text messages and emails) for less than $30-50/year. So, after doing a little research, I found I could offer the exact service I wanted for around $10-15/year (that's $1.00-1.50/month) if I did it on my own. And so I built Server Check.in.
Server Check.in uses Stripe for payment acceptance (leagues beyond PayPal in terms of UX and DX), Twilio for SMS notifications ($0.01/message is bearable, and means there's room for a small profit), and Drupal on a LAMP server. Drush ('DRUpal SHell') handles most of the back-end (processing queues, checking servers, etc.), and I built the responsive HTML5 theme using Zen. Three custom modules drive the site, and integrate the notification and payment services. I have a post that explains the architecture with more detail here: http://www.lifeisaprayer.com/blog/2012/server-checkin-websit...
I stuck with what I know (a LAMP stack) for this project, though I'm dabbling in Python and Node.js to see if I might want to move more of the backend services away from PHP and shell scripting. I hope the service will grow large enough that I'll need to expand horizontally, but right now there's plenty of room for an initial batch of users.
Also, check out the 404 page; I made a little easter egg that I hope I can make more interesting over time :)
I'd appreciate any feedback; especially any ideas for improvement, or ways I could make it a more enticing service for other developers.
If you'd like to sign up, here's a coupon code for 20% off your first year: hn_twenty_off