The right price is the price your target consumers are willing to pay. And if like another commenter you are doing to build it yourself instead of forking $19, you obviously are not the consumer. (and neither am I - I'll stick to cron :-) !)
Part of this value is that their service keeps running. That is, you could set-up their service yourself (a process which expects to be pinged periodically, and emails/SMSs you if it isn't), but what if that service itself fails? (who shall watch the watcher)
It's not perfect: your periodic task might ping them, but not work fully (e.g. backup script runs, but didn't actually backup). You need some kind of verification (test-code) for your tasks that must succeed before you ping them. This is something they could help customers with - using blogs, articles, case-studies, and especially example code for common tasks (e.g. backup) etc. This would really help people (and incidentally publicize their service). Also, I love this copy:
"Once you use it, you realize you've been doing it wrong for years."
What I will say is that I probably would want to be able to set up 3-5 snitches before I'd feel comfortable committing to setting a bunch more up, which incidentally, is also the point I'd be willing to start paying money.
It is very easy to be notified when something happens (for example, MAILTO in cron) but it's hard to know when something DOESN'T happen, especially if you work on a lot of sites.
There are plenty of ways to be notified when something doesn't happen if you are willing to use a little elbow grease... we use one of them to make sure DMS itself is working properly.
A "Pricing" page in your navigation would be ideal, IMO. Even an entry in the FAQ ("How much does this cost?") would suffice, especially if it's the top item.
You can monitor web services, processes, file modified dates, directories, loads of stuff all with email alerts and a web-front end too.
I know I could use this for 3 things on my own, but would probably rather just build it myself than pay $19/month. (although that is definitely more than reasonable if I wasn't using this for just independent projects)
I think most SLAs for these types of services are mostly pointless anyway. If something important to your business goes down, are you really going to be worried about whether or not you have to pay the $19?
EDIT: If you have reasonable default tolerances or the ability to set tolerances on tasks, I'm pretty interested in trying it out - do you integrate or have plans to integrate with pagerduty, or do you simply fire off an email?
We don't replace something like monit to make sure your process continues to run, we are validation that one-off periodic things run... things that are easy to forget about but are important.
This actually happened over the weekend:
I'd go further and say, that most of people willing to pay that much (serious about their backups and availability) already have some solution in place.
The service is very appealing for people, who don't really care that much (because it's very easy to use). I'm afraid that those people won't pay $19/mo.
Smart people go after customers willing to pay more.
Actually, I have some old cheap clients I fired some time ago... Should I send them your way? They need someone to yell at and then laugh at when the cost of their needs are quoted.
1) Disclose cost earlier. Telling people to sign up for free and then asking them to pay you is not cool. It starts off the relationship on a bad note and will prevent people from signing up.
2) You have a great idea here. Startups need this. We do not have time to set up and configure nagios, or some other warning mechanism. You make a good start by attacking the problem no one else actually wants to take care of, and making it really easy to do so.
3) Either forget the hobbyist or make another (less expensive) level of service for him. Do not forget there is very little money to be made on hobbyists unless it is very easy for you to take them on. You do not want to take on these people asking for the same service for $1 unless you can make it much cheaper to provide service to them.
4) As some have noted: Put in a SLA, and tell us why your service will not fail. Otherwise if we are not warned we will not know if it's because your service is down.
5) Put up a tutorial or more info on what you offer. Can we have planned maintenances (ie, do not warn me about this for 4 hours)? Can we hit the snooze button? What are the methods you use for notifications? How many people/emails/phones will be notified per failure? The unanswered questions go on and on.
6) Do more stuff. What about other type of monitoring? Can we group servers into groups so we do not have to set up each individually? Can we monitor stuff that IS running but I send you a value periodically through the HTTP hit? I want to graph stuff, like HTTP hits per hour, or HTTPD errors per minute. I want a warning to be sent to me when I get more than X HTTPD errors per minute, for example.
EDIT: 7) Add a trial period, this just makes sense.
So for work I run Nagios. I would love to have a Nagios set up for my side projects because Nagios provides a world of benefits but if I invested my time in setting up Nagios then I would not have time to do actual development.
You are onto something good, you just need to shape it a bit.
Like this site and it's simplicity a lot already, I think there's a lot more interesting things to explore before you'd get on with the feature creep. Good job!
That is when your cron job runs but there is some error in part of the script (for example maybe it writes/reads a file in a folder but the permissions on that folder were changed since the script was written). This causes an error which might cause a cascade of errors meaning that some other parts of your job either fail to run or run incorrectly.
Now what happens here, do you get notified of the error or does it just get silently eaten? It's also very possible that your system will eat the error and then proceed to the next step (calling this API) and everything will appear fine.
One thing I figure out what the expected output from the job should be, I then pipe the output from the cronjob into a file. I have a second cronjob that checks the contents of this file periodically and generates an alert if it does not match what is expected.
You should also try and find some way to test any generated data. For example if you are doing a DB backup, add another table with a field that contains data that is in some way based on the date. You can then have a task which will try and restore old backups into another DB, it can then check this field against the expected value for the date of the backup.
Of course none of these techniques are silver bullets and there are plenty of things that can go wrong, it is certainly prudent to check things manually every once in a while.
Perhaps this API could be modified to take as an input the output from scheduled tasks and check them?
If you have a way of checking things like this, great! You should keep doing that!
You may also have to consider warning conditions which might be more catastrophic to your "pipe" that the original program would believe.
1 23 * * * /home/cron/backup.sh 1> /backups/backup
and monit doing a
check file backup with path /backups/backup
if timestamp > 24 hours then alert
This way I am emailed when there is an error with the backup script, otherwise things continue as it is.
It has named cron jobs, @noauto and AFTER keywords, which let you run jobs depending on whether previous jobs (identified by name) have run successfully.
That, combined with using things like && and || and mailx, give you quite powerful ways of checking on previous cron jobs.
I hope your endeavors continue to make you happy with your means as they do mine.
As far as making sure DMS runs, we use another third-party to make sure our checkers run. Contact support if you are interested in finding out more.
$ curl https://nosnch.in/c2354d53d2
Dead Man's Snitch does not ping your servers. It is the opposite way around. If your server stops pinging Dead Man's Snitch, you will be notified.