How to edit your crontab

In this article, we'll introduce crontabs, discuss the different methods available to edit crontabs, and share how to avoid some common issues associated with crontab editing. At the end, we'll introduce Airplane which is a developer platform for building internal tools. Airplane supports maintenance-free scheduling and comes with a free pricing plan.

What is a cron job?

Cron is a job-scheduling utility available in Unix and Unix-like operating systems. It executes recurring tasks at specified intervals (e.g., hourly, daily, weekly, yearly, and so on) using the cron daemon.

Cron jobs are often used for scheduling repetitive operations. For example, a cron job might execute a script that sends emails to users on a specific day. Since these jobs are highly customizable, you can do things like set a cron job to run every 60 minutes or only run on specific days of the week.

Cron jobs can be very effective tool for scheduling tasks such as:

• Sending out weekly newsletters to subscribers
• Running health checks to monitor system health and resource capacity
• Taking regular database backups
• Syncing data across two systems
• Exporting order data for processing
• Generating invoices for your customers
• Creating a monthly report of your growth metrics
• Monitoring for slow queries
• and much more

What is a crontab?

A crontab is a file that specifies commands and scripts that are executed on a predetermined schedule with the help of the cron utility. The cron utility allows for a great deal of flexibility in setting up recurring schedules. While you can make simple recurring schedules for daily, weekly, and monthly jobs and customize them as needed, cron also enables you to set up nuanced schedules, such as run at "4pm on every second Monday of the month".

A crontab file helps you prepare commands for scheduled execution via the cron daemon. For example, let's assume you have a script (send-newsletter.sh) that contains functionality to send a newsletter to customers. The following crontab entry will send the newsletter out every Monday at seven in the morning:

0 7 * * 1 /usr/bin/send-newsletter.sh

Crontab format

People often ask what the right crontab format is. Let's reference the example above to describe what each entry in a crontab means. The following crontab entry will send out a customer newsletter every Monday at seven in the morning: 0 7 * * 1 /usr/bin/send-newsletter.sh

In the table below, we've described what each entry means, starting from the left.

You can reference the crontab format in the following:

More information about the scheduling format can be found here.

Please note that each user, including the root user, has a separate crontab file. There are multiple ways to edit crontab files. In the following sections, we'll discuss the different methods available to edit crontabs, as well as how to avoid some common issues with crontab editing.

Edit crontab

Cron jobs are very useful for managing day-to-day scheduled operations. When it's time to update your jobs and add new tasks for new use cases, you'll need to edit the crontabs. Let's discuss the most common ways to edit your crontabs.

How to edit crontab

crontab -e

The most common way to edit your crontab is to use the -e flag with the crontab command: crontab -e. This command will open your crontab file in the system’s default text editor. You can then edit and make changes as needed. Remember to save your changes when you're finished editing and exit the editor.

Let’s take a look at the steps required if you want to change the example task schedule above to send the newsletter every Tuesday instead of every Monday.

Check that the crontab schedule exists using the crontab -l command:

Now use the crontab -e command to edit the crontab. This will bring up the default text editor on your system and open the crontab in edit mode. If you don’t have a default editor set in your operating system preferences, you'll get a prompt to select one.

The field in the day-of-the-week slot is set to 1. Let's update it to 2 for Tuesday instead of 1 for Monday. Remember to save your changes before you exit the editor.

When using the crontab -e command, it is important to note that the tasks scheduled via the crontab will be executed using the crontab owner’s privileges. If a script requires permissions that your user account does not have (such as root or admin access), the cron daemon might not be able to execute the task at all.

Edit the crontab file directly (not recommended)

The operating system stores crontab on your file system, so you can edit it like any other file. For example, in most flavors of Linux, you will find this file in the /var/spool/cron/crontabs/ folder. It might seem straightforward to edit it directly, bypassing the crontab -e command, however, this approach isn't recommended for several reasons.

• crontab -e sets up a temporary file in your system's temporary directory (/tmp) and your edits are being made to that file before being applied to the actual crontab file. This mechanism ensures that the actual crontab file isn't modified until you're done making changes and the changed file has been checked for formatting and syntactical errors. Without this check, you could end up accidentally corrupting your file, and not even realize it until the script doesn't run as expected.
• You'll need elevated (root) permissions to edit the crontab file directly. The root password is usually restricted to very few users since it has unlimited administrative permissions on the server.

Remove crontab file

To remove the current crontab file, run the command crontab -r.

Edit another user's crontab file

To edit another user's crontab files, run the command crontab -u <username>. Note that running this command requires that you have system administrator privileges.

Common issues with editing crontab files

System administrators tend to face a common set of issues when working with crontab files. In this section, we'll discuss some of the problems users face when editing crontab files and share some workarounds.

Cron daemon failures and troubleshooting challenges

The cron daemon is the background process that provides cron functionality. Like any other process, it can encounter failures. If the host system runs out of memory to start new threads or to continue running processes, the cron daemon might fail to execute the cron task. Batch processing and data-intensive tasks are always at risk of bloating system memory if not managed properly.

Cron issues can be difficult to troubleshoot. The logs from cron task execution are stored at /var/log/syslog or /var/log/. In AWS-based environments, the logs might be stored at /var/log/cron as well. These log files are recycled after some time. This means that by the time you realize there's a problem, the associated logs may have already been recycled making it very difficult to diagnose issues. Additionally, debugging becomes more difficult when errors are mixed with other details in system log files. This requires a lot of time to find the error and separate it for that specific time and execution.

In many cases, you can spend hours trying to figure out why a crontab stopped working. For example, you might have to edit the cron schedule to run more frequently, then run it so you can analyze the logs. Having a specific and clear report or stack trace that can inform the reason for the failure of a scheduled task is very valuable in such cases.

A scheduling tool with dedicated logging capabilities can help you debug issues easily. Such tools can also present you with reports on how your schedules have been performing over particular intervals and can send out alerts when a task seems to be behaving unusually, such as running too long or taking up too much memory.

Missing permissions

Another common issue is the failure of cron tasks due to missing permissions. If the script to be executed was written and tested by a user with one set of permissions, such as an administrator, but scheduled by an account that doesn't have those permissions, the script may not have sufficient permissions to run as expected.

When editing crontab files, you have no way of knowing if the task that you’re scheduling can be executed with your account’s permissions. If the cron daemon executes the task on the set schedule and it fails, you'll have to dig through piles of logs and traces to figure out what went wrong.

Problems like this can usually be eliminated with a cloud-based task scheduler. A scheduler that allows you to collaborate with your teammates when working on tasks will generally alert you if your user account does not have the privilege to edit or schedule a task.

Incorrect environment variables

Missing environment variables is another issue that causes crontab execution failures. If your script is looking for environment variables, they must be set in advance. If you don't set them when scheduling the crontab task, it'll fail.

For scripts that access external resources, a key or a token is often required. Environment variables are used to store these so that when the script is shared with someone else, the key or token is not exposed.

Crontab has no special focus on environment variables. For tasks scheduled with crontab, you can set the environment variables in the ~/.bash_profile file, the /etc/environment file, or even in the crontab file itself. This makes it difficult to manage the environment variables, since you have to look in multiple places every time you're looking to edit one.

A task scheduler that has a clear strategy for adding and maintaining environment variables when scheduling tasks can be helpful. In addition to using a single store for all environment variables, having a UI to update the variables also makes it easier to test and to try different values for parameters.

Lack of UI and central management

In a typical IT environment, servers usually have multiple users, each with their own crontabs. This makes it difficult to get a comprehensive view of all tasks that are scheduled on the server. For example, you could have backup jobs scheduled under one user, while email jobs are scheduled by a different user. Without central tracking and management of the various tasks, you can end up with a messy set of operations and duplicate jobs, and waste time locating and managing specific tasks.

One suggestion is to have a set of system admins that are responsible for managing your cron jobs and making edits to crontabs. You can also invest in a cloud-based scheduling tool which typically provides a user interface for task management. Many cloud-based solutions allow team members to contribute tasks to common folders while retaining their ownership and/or editing rights on it.

These were just a few common issues that are faced when editing crontabs. For more information on cron troubleshooting, you can check out the following post: Top Reasons your Cron Job Isn't Running

Airplane: a maintenance-free alternative to cron

While cron is one of the most common scheduling tools among developers, it has its limitations when it comes to scaling organizations. In this article, we discussed how to edit your crontab and shared some common issues associated with editing crontabs.

There are many other enterprise-grade scheduling tools out there that serve as great alternatives to cron and can help you avoid these issues. One such tool is Airplane, which is a developer platform for transforming code into internal apps quickly. Airplane also supports maintenance-free and serverless job scheduling.

Using Airplane, you can turn APIs, SQL queries, and scripts into tasks and either configure them to run on schedules or run them manually.

Since Airplane schedules are tightly integrated with the rest of the Airplane ecosystem, you get full visibility into past, present, and running jobs and can leverage built-in notifications for run failures, role-based access controls, audit logging, and an easy-to-use UI for managing jobs centrally.

You can also subscribe to alerts on your tasks in Airplane that can be sent via email or Slack for easy debugging. Additonally, Airplane's Activity page allows you to view and filter all of your account's activity. You can access the logs of each execution individually, and export and share them as necessary.

You can also manage, edit, and pause your schedules centrally using Airplane's Schedules page:

Airplane: developer-first internal tools

Airplane is a developer-first platform for building powerful internal applications. You can transform APIs, scripts, and SQL queries into UIs and workflows in minutes and replace brittle cron jobs with scheduled tasks.

While this article focused primarily on scheduled operations, you can use Airplane for a lot more than just scheduled jobs. Tasks are the building blocks of Airplane and can be used for anything from single- step operations (restart a microservice, hit an API endpoint) to elaborate multi-step functions (customer onboarding workflow, admin panel for customer support).

Airplane also makes it incredibly easy to build custom UIs, called Views, that you can share with your team safely. There are several benefits to using Airplane Views to build custom UIs and internal dashboards. These include access to a rich component library, an extensive template library to help get started quickly, and first-class security.

Finally, Airplane provides enterprise-grade functionality out of the box such as permissions, audit logs, and approval flows, so all you have to focus on is writing the business logic for your internal operations.

If you'd like to try Airplane out, you can sign up for a free account using the 'Sign up' button on the top right! You can also check out the Airplane blog for more cron-related content such as creating Golang cron jobs, mastering Kubernetes Jobs and Kubernetes CronJobs, and how to run cron in containers.