{"id":6033,"date":"2026-06-19T09:45:30","date_gmt":"2026-06-19T06:45:30","guid":{"rendered":"https:\/\/www.scalahosting.com\/kb\/?p=6033"},"modified":"2026-06-19T09:45:31","modified_gmt":"2026-06-19T06:45:31","slug":"add-edit-delete-cron-jobs-spanel","status":"publish","type":"post","link":"https:\/\/www.scalahosting.com\/kb\/add-edit-delete-cron-jobs-spanel\/","title":{"rendered":"How to Add, Edit, and Delete Cron Jobs in SPanel"},"content":{"rendered":"\n

SPanel’s form-based Cron Job Manager covers the three things you do most with scheduled tasks: add a job, change one in place, and remove one. In the SPanel user interface, open the Cron Jobs<\/strong>, then use the Create a New Cron Job<\/strong> form, Edit<\/strong>, or Delete <\/strong>on a job’s row.

The key limit<\/strong>: an edit or delete is an exact-match, in-place change to a single job line – no multi-select, no bulk edit – so each action touches only the job you picked and leaves the rest of your crontab alone. New jobs are quiet by default too: an empty MAILTO means adding a job does not start emailing its output.<\/p>\n\n\n\n

Who this is for<\/strong><\/h2>\n\n\n\n

This guide is for the person who runs scheduled tasks on a ScalaHosting managed VPS and wants to manage them without a terminal – usually a small business owner with a nightly backup or recurring report. Digital agencies and developers will find this operation useful as well. You do not need shell experience, only the SPanel user interface and a command to run on a schedule. To confirm a job works before trusting the schedule, see the related guide below.<\/p>\n\n\n\n

What problem this solves<\/strong><\/h2>\n\n\n\n

The old way to manage scheduled tasks is crontab -e over SSH: one shared file, every job on its own line, no guardrails. The danger is not writing a new line – it is everything around it. A stray keystroke on another row, a deleted character in a path, and a job that ran for months stops firing. One careless edit can break every job in the file – no warning, no undo.<\/p>\n\n\n\n

How SPanel solves this<\/strong><\/h2>\n\n\n\n

SPanel replaces the raw file with a form. Open the Cron Jobs Manager<\/strong> and your jobs appear as a list, one row each. <\/p>\n\n\n\n

To add<\/strong>, fill in the five schedule fields and the command and save; to edit<\/strong>, open a row and change what you need – most often the schedule; to delete<\/strong>, remove a row after a confirmation. You work on one job at a time, and the form does the crontab editing, so the mistakes that break a hand-edited file never happen.<\/p>\n\n\n\n

Why this is different in SPanel<\/strong><\/h2>\n\n\n\n

Two specifics make this safer than a hand edit.<\/p>\n\n\n\n

    \n
  • Edit and delete are exact-match, single-line changes.<\/strong> When you edit a job, SPanel replaces only the line you selected; when you delete one, it removes only that line. Every other job stays byte-for-byte as it was. There is no multi-select and no bulk edit – which is the safety feature: you cannot affect a neighboring job by accident.<\/li>\n\n\n\n
  • New jobs are silent by default.<\/strong> A standard crontab emails the output of every run, so a fresh job on a busy schedule can flood your inbox. SPanel ships with an empty MAILTO – the cron setting that decides where output is emailed – so output goes nowhere and your added job runs quietly. Want the emails? Set MAILTO yourself; nothing arrives by surprise.<\/li>\n<\/ul>\n\n\n\n

    Before you start<\/strong><\/h2>\n\n\n\n

    You will need:<\/p>\n\n\n\n

      \n
    • A ScalaHosting managed VPS with SPanel, signed in to the SPanel user interface (not the admin area).<\/li>\n\n\n\n
    • The command to schedule, with full absolute paths – a relative path that works in your shell often fails under cron.<\/li>\n\n\n\n
    • A schedule in mind, such as “every day at 3 AM.” The next section shows how to write it in cron’s five fields.<\/li>\n<\/ul>\n\n\n\n

      Step-by-step<\/strong><\/h2>\n\n\n\n

      We will add a harmless job, change its schedule in place, then delete it. <\/p>\n\n\n\n

      The example has no application-side effects: it only appends one line to a test log file: \/bin\/echo “cron ran” >> \/home\/USER\/kb-test\/cron.log. Before adding the test cron job, create \/home\/USER\/kb-test\/ or replace the path with an existing directory in your account.<\/p>\n\n\n\n

        \n
      1. In the SPanel user interface, open Cron Jobs Manager<\/strong>. Your jobs appear as a list with their schedules and commands.<\/li>\n<\/ol>\n\n\n\n
        \"How<\/figure>\n\n\n\n
          \n
        1. Add a job.<\/strong> Fill in the five schedule fields and the command, then save. For “every day at 3:00 AM,” the schedule is 0 3 * * *, with the command echo “cron ran” >> ~\/kb-test\/cron.log.
          The five schedule fields.<\/strong> Cron reads a schedule as five values in order: minute<\/strong> (0\u201359), hour<\/strong> (0\u201323), day-of-month<\/strong> (1\u201331), month<\/strong> (1\u201312), day-of-week<\/strong> (0\u20136, where 0 is Sunday). A * means “every.” A few examples:<\/li>\n<\/ol>\n\n\n\n
            \n
          • 0 3 * * * – every day at 3:00 AM.<\/li>\n\n\n\n
          • *\/15 * * * * – every 15 minutes, all day.<\/li>\n\n\n\n
          • 30 2 * * 1 – 2:30 AM every Monday.<\/li>\n<\/ul>\n\n\n\n
            \"How<\/figure>\n\n\n\n
              \n
            1. Confirm the job was added.<\/strong> Save returns you to the list, where the new job appears as its own row.<\/li>\n<\/ol>\n\n\n\n
              \"How<\/figure>\n\n\n\n
                \n
              1. Edit the job in place.<\/strong> Open Actions<\/strong> – Edit<\/strong> on the new job’s row. The form opens pre-filled. Change only the schedule – from 3:00 AM to 4:30 AM (minute 30, hour 4, the rest *) – and save.<\/li>\n<\/ol>\n\n\n\n
                \"How<\/figure>\n\n\n\n
                  \n
                1. Confirm the edit, and that the rest are intact.<\/strong> Back in the list, the edited job shows its new schedule while every other job is unchanged – the exact-match edit touched one line and left the neighbors alone.<\/li>\n<\/ol>\n\n\n\n
                  \"How<\/figure>\n\n\n\n
                    \n
                  1. Delete the job.<\/strong> Use Delete<\/strong> on its row and confirm. SPanel removes only that line, and the rest of your schedule is intact.<\/li>\n<\/ol>\n\n\n\n
                    \"How<\/figure>\n\n\n\n

                    What happens behind the scenes<\/strong><\/h2>\n\n\n\n

                    SPanel reads and writes your user’s crontab – the same file crontab -e opens. When you add, edit, or delete, it rewrites that file, replacing or removing only the targeted line and copying the rest through unchanged. That is why one action never disturbs a job you did not select.<\/p>\n\n\n\n

                    Limitations and edge cases<\/strong><\/h2>\n\n\n\n

                    You work one job at a time: no multi-select<\/strong> (five edits for five jobs) and no bulk delete<\/strong>. The panel manages the standard five-field schedule; it does not offer one-time “run once at this date” scheduling, automatic retries, or a drag-and-drop schedule builder. Because a fresh job is silent by default, “I added it but got no email” is expected, not a failure.<\/p>\n\n\n\n

                    Troubleshooting<\/strong><\/h2>\n\n\n\n
                    Symptom<\/td>Likely cause<\/td>What to do<\/td><\/tr>
                    Added job never seems to run<\/td>Schedule fields are off, or the command uses a relative path<\/td>Re-check the five fields; use full absolute paths<\/td><\/tr>
                    No email after adding a job<\/td>Empty MAILTO default – output is not mailed<\/td>Expected; set MAILTO if you want emails<\/td><\/tr>
                    Edited the wrong job’s schedule<\/td>Two rows looked alike<\/td>Open the right row by its command; the others were untouched<\/td><\/tr>
                    Job still runs after you deleted it<\/td>Confirmation dismissed, or a duplicate line exists<\/td>Confirm the row is gone; delete any duplicate<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

                    When to use \/ when not to use<\/strong><\/h2>\n\n\n\n
                    Use the Cron Job Manager when<\/td>Reach for something else when<\/td><\/tr>
                    You want to add, change, or remove a recurring task without SSH<\/td>You need a task to run exactly once at a future date<\/td><\/tr>
                    You want to change one job’s schedule and leave the rest alone<\/td>You want automatic retries or failure alerts on a job<\/td><\/tr>
                    You prefer a form over editing a raw crontab<\/td>You are confirming a brand-new job actually works (test it first)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

                    FAQ<\/strong><\/h2>\n\n\n\n

                    Q:<\/strong> Will editing one cron job change the others?<\/strong> <\/p>\n\n\n\n

                    A:<\/strong> No. SPanel matches the exact line of the job you opened and rewrites only that line. The others stay as they were.<\/p>\n\n\n\n

                    Q:<\/strong> Can I edit or delete several jobs at once?<\/strong> <\/p>\n\n\n\n

                    A:<\/strong> No. There is no multi-select or bulk edit – you work one job at a time. That is deliberate: an action cannot catch a job you did not mean to touch.<\/p>\n\n\n\n

                    Q:<\/strong> Why didn’t I get an email when my new job ran?<\/strong> <\/p>\n\n\n\n

                    A:<\/strong> No email is expected by default because SPanel uses an empty MAILTO= setting. To confirm the job actually runs, use the related \u201ctest a cron job before it runs\u201d guide or check the job\u2019s output\/log file.<\/p>\n\n\n\n

                    Q:<\/strong> Does deleting a job in SPanel remove it from the real crontab?<\/strong> <\/p>\n\n\n\n

                    A:<\/strong> Yes. SPanel writes your real user crontab, so deleting a job removes that line from the file the scheduler reads.<\/p>\n\n\n\n