41–50 of 52 posts
Here's a shot at giving constructive feedback rather than bitching about the cost which most people here are doing. Point taken, there's the other stuff I can think of: 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 no…
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?
The problem is that this doesn't address what I have found to be the most dangerous problem with periodic tasks. 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…
If you have a way of checking things like this, great! You should keep doing that!
The problem is that this doesn't address what I have found to be the most dangerous problem with periodic tasks. 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…
You have to make sure your periodic tasks acts in such a way that if a piece fails, the rest doesn't execute (using && for instance). Then you would add hitting your special url the last thing to execute. 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.
Earlier quoted context omitted.
^^^ this. Plus you say "Sign up for free" in the home page. At the very least it's misleading.
I'm not sure how it's misleading. You can sign up and have one snitch for free. It would be misleading if I said sign up for free and then didn't allow you to create ANY snitches without paying.
To those complaining about the price - the level of technicality, like for MAILTO=user@domain.com in a crontab may not explain the price alone. Price != costs. 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."
Here's a shot at giving constructive feedback rather than bitching about the cost which most people here are doing. Point taken, there's the other stuff I can think of: 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 no…
Thanks! I'll think on some of this stuff and probably incorporate some of it.
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!
Earlier quoted context omitted.
^^^ this. Plus you say "Sign up for free" in the home page. At the very least it's misleading.
I'm not sure how it's misleading. You can sign up and have one snitch for free. It would be misleading if I said sign up for free and then didn't allow you to create ANY snitches without paying.
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.