Dead Man's Snitch

Posts About Crontab

Creating a Test Snitch

The first thing a lot of users do is create an hourly test Snitch to see how Dead Man’s Snitch works. Don't worry, you can delete it at any time.

1. Name your Snitch and set the interval to Hour. You can set a Snitch-specific email address if it's different than your account email. Click Save.

2. The next page displays your unique Snitch URL and methods for installing it: cURL, email, and Ruby. To kick off the checking process request the URL using any of these three methods. The most common and basic method is using cURL and would look something like:

$ run_backups_or_something && curl

For the purpose of the test Snitch, cURL only the Snitch URL in terminal or paste the Snitch URL in your browser.

3. Head back to your dashboard. Your Snitch status light should now be a green checkmark. Since you're checking in your Snitch manually it won't be pinged in the next hour (unless you do it manually) and you’ll receive an alert email.

Note: Hourly snitches check in on the hour, every hour. Keep this in mind when you hit the Snitch URL since the first check-in may take longer than you expected. For example: If you hit the URL for the first time at 1:55 PM and your snitch doesn’t check in between 2-3 PM, you’ll receive an alert around 3:01 PM. However, if you hit the URL for the first time just after the hour, say, 2:10 PM and your snitch doesn’t check-in (from 3-4 PM), you won’t receive an alert until 4:01 PM. Since the URL was hit after the hour, the first full period is from 3-4 PM. Your snitch will continue to check-in every hour, on the hour thereafter. This blog post goes into more detail on snitch check-ins and alerts.

Posted on 2014-03-18 in crontab, devops, faq, sysadmin, testing

Using Crontab? You Should be using a Monitoring Tool & Here's Why.

If you’re familiar with crontab in Linux, there’s a good chance you’re equally familiar with the infamous cron job silent failures. Many of us sysadmins and developers have experienced these failures without knowing before it’s too late. Automated backups and sending monthly emails aren’t always as automated (or on time) as we tend to think. Herein lies the problem.

My cron jobs send me an email when they run…isn’t that enough?

That can be true, but is there REALLY any value in knowing that they ran? Isn’t that why you created the cron job in the first place–so that it does its job? Sure, receiving an email of cron output after it runs is great. However, the value lies in knowing when your cron jobs FAIL to run (or are delayed). Then, you can investigate and fix the problem before it’s too late. Not convinced? Consider this example from a long time DMS user, Kareem Mayan, co-founder of

A little background:

“At we do workout tracking for gyms. When a new workout is emailed to us from a customer (in the form of a photo of a whiteboard, which has the workout and results), we put the data online. Once it’s online, we email that gym’s clients telling them new workout results have been posted.

Great. Where’s the problem?

"When Delayed Job (DJ) failed silently, we wouldn’t know until me or my co-founder was prompted to look based on seeing something funny, e.g. seeing a Stripe email about a new customer signup but NOT seeing the automated welcome email to the new customer (sent by our system… which was waiting in the database, ready for DJ to pick it up, which would never happen because that process had died).”  
"The result would often be several days of emails (THOUSANDS of emails) queued up until one of us manually restarted DJ. This sucked because customers would either get a ton of emails in once, and some would be days old, or we would delete those emails before they got sent. This also sucked because customers would never get notifications about their posted results.”

How did Dead Man’s Snitch help?

"Using Dead Man’s Snitch made that problem go away. Now, if DJ dies, DMS never gets pinged, and we get an email as soon as that happens. At most we’ll go five minutes - not days - before knowing that we need to kick DJ into action again.”

If you can relate and want the peace of mind in knowing right when your cron jobs fail, give Dead Man’s Snitch a try and sign up for free. After all, your first snitch is on us. However, if you can’t relate but you actually made it to the end, I applaud you. If this topic doesn’t relate to you, there’s a good chance your computer friends, IT department or website managers would. Do them a favor and pass this on.

Happy Snitching!

(Do you have a story of how DMS is helping you? Let’s talk:

Posted on 2013-10-16 in backups, crontab, DMS in Practice, linux