{ "id": "c95bf39d-e0dd-4518-82d2-da5b7e8c07b9", "created_at": "2026-04-06T00:15:43.384188Z", "updated_at": "2026-04-10T13:12:45.111051Z", "deleted_at": null, "sha1_hash": "a11374479d4937e054cfab8e6ef25b4152a29ad7", "title": "CronJob", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 97308, "plain_text": "CronJob\r\nArchived: 2026-04-05 17:37:21 UTC\r\nA CronJob starts one-time Jobs on a repeating schedule.\r\nFEATURE STATE: Kubernetes v1.21 [stable]\r\nA CronJob creates Jobs on a repeating schedule.\r\nCronJob is meant for performing regular scheduled actions such as backups, report generation, and so on. One\r\nCronJob object is like one line of a crontab (cron table) file on a Unix system. It runs a Job periodically on a given\r\nschedule, written in Cron format.\r\nCronJobs have limitations and idiosyncrasies. For example, in certain circumstances, a single CronJob can create\r\nmultiple concurrent Jobs. See the limitations below.\r\nWhen the control plane creates new Jobs and (indirectly) Pods for a CronJob, the .metadata.name of the\r\nCronJob is part of the basis for naming those Pods. The name of a CronJob must be a valid DNS subdomain value,\r\nbut this can produce unexpected results for the Pod hostnames. For best compatibility, the name should follow the\r\nmore restrictive rules for a DNS label. Even when the name is a DNS subdomain, the name must be no longer\r\nthan 52 characters. This is because the CronJob controller will automatically append 11 characters to the name you\r\nprovide and there is a constraint that the length of a Job name is no more than 63 characters.\r\nExample\r\nThis example CronJob manifest prints the current time and a hello message every minute:\r\napiVersion: batch/v1\r\nkind: CronJob\r\nmetadata:\r\n name: hello\r\nspec:\r\n schedule: \"* * * * *\"\r\n jobTemplate:\r\n spec:\r\n template:\r\n spec:\r\n containers:\r\n - name: hello\r\n image: busybox:1.28\r\n imagePullPolicy: IfNotPresent\r\n command:\r\n - /bin/sh\r\n - -c\r\nhttps://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/\r\nPage 1 of 6\n\n- date; echo Hello from the Kubernetes cluster\r\n restartPolicy: OnFailure\r\n(Running Automated Tasks with a CronJob takes you through this example in more detail).\r\nWriting a CronJob spec\r\nSchedule syntax\r\nThe .spec.schedule field is required. The value of that field follows the Cron syntax:\r\n# ┌───────────── minute (0 - 59)\r\n# │ ┌───────────── hour (0 - 23)\r\n# │ │ ┌───────────── day of the month (1 - 31)\r\n# │ │ │ ┌───────────── month (1 - 12)\r\n# │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday)\r\n# │ │ │ │ │ OR sun, mon, tue, wed, thu, fri, sat\r\n# │ │ │ │ │\r\n# │ │ │ │ │\r\n# * * * * *\r\nFor example, 0 3 * * 1 means this task is scheduled to run weekly on a Monday at 3 AM.\r\nThe format also includes extended \"Vixie cron\" step values. As explained in the FreeBSD manual:\r\nStep values can be used in conjunction with ranges. Following a range with /\u003cnumber\u003e specifies skips\r\nof the number's value through the range. For example, 0-23/2 can be used in the hours field to specify\r\ncommand execution every other hour (the alternative in the V7 standard is\r\n0,2,4,6,8,10,12,14,16,18,20,22 ). Steps are also permitted after an asterisk, so if you want to say\r\n\"every two hours\", just use */2 .\r\nNote:\r\nA question mark ( ? ) in the schedule has the same meaning as an asterisk * , that is, it stands for any of\r\navailable value for a given field.\r\nOther than the standard syntax, some macros like @monthly can also be used:\r\nEntry Description Equivalent to\r\n@yearly (or @annually) Run once a year at midnight of 1 January 0 0 1 1 *\r\n@monthly Run once a month at midnight of the first day of the month 0 0 1 * *\r\n@weekly Run once a week at midnight on Sunday morning 0 0 * * 0\r\nhttps://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/\r\nPage 2 of 6\n\nEntry Description Equivalent to\r\n@daily (or @midnight) Run once a day at midnight 0 0 * * *\r\n@hourly Run once an hour at the beginning of the hour 0 * * * *\r\nTo generate CronJob schedule expressions, you can also use web tools like crontab.guru.\r\nJob template\r\nThe .spec.jobTemplate defines a template for the Jobs that the CronJob creates, and it is required. It has exactly\r\nthe same schema as a Job, except that it is nested and does not have an apiVersion or kind . You can specify\r\ncommon metadata for the templated Jobs, such as labels or annotations. For information about writing a Job\r\n.spec , see Writing a Job Spec.\r\nDeadline for delayed Job start\r\nThe .spec.startingDeadlineSeconds field is optional. This field defines a deadline (in whole seconds) for\r\nstarting the Job, if that Job misses its scheduled time for any reason.\r\nAfter missing the deadline, the CronJob skips that instance of the Job (future occurrences are still scheduled). For\r\nexample, if you have a backup Job that runs twice a day, you might allow it to start up to 8 hours late, but no later,\r\nbecause a backup taken any later wouldn't be useful: you would instead prefer to wait for the next scheduled run.\r\nFor Jobs that miss their configured deadline, Kubernetes treats them as failed Jobs. If you don't specify\r\nstartingDeadlineSeconds for a CronJob, the Job occurrences have no deadline.\r\nIf the .spec.startingDeadlineSeconds field is set (not null), the CronJob controller measures the time between\r\nwhen a Job is expected to be created and now. If the difference is higher than that limit, it will skip this execution.\r\nFor example, if it is set to 200 , it allows a Job to be created for up to 200 seconds after the actual schedule.\r\nConcurrency policy\r\nThe .spec.concurrencyPolicy field is also optional. It specifies how to treat concurrent executions of a Job that\r\nis created by this CronJob. The spec may specify only one of the following concurrency policies:\r\nAllow (default): The CronJob allows concurrently running Jobs\r\nForbid : The CronJob does not allow concurrent runs; if it is time for a new Job run and the previous Job\r\nrun hasn't finished yet, the CronJob skips the new Job run. Also note that when the previous Job run\r\nfinishes, .spec.startingDeadlineSeconds is still taken into account and may result in a new Job run.\r\nReplace : If it is time for a new Job run and the previous Job run hasn't finished yet, the CronJob replaces\r\nthe currently running Job run with a new Job run\r\nNote that concurrency policy only applies to the Jobs created by the same CronJob. If there are multiple CronJobs,\r\ntheir respective Jobs are always allowed to run concurrently.\r\nhttps://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/\r\nPage 3 of 6\n\nSchedule suspension\r\nYou can suspend execution of Jobs for a CronJob, by setting the optional .spec.suspend field to true. The field\r\ndefaults to false.\r\nThis setting does not affect Jobs that the CronJob has already started.\r\nIf you do set that field to true, all subsequent executions are suspended (they remain scheduled, but the CronJob\r\ncontroller does not start the Jobs to run the tasks) until you unsuspend the CronJob.\r\nCaution:\r\nExecutions that are suspended during their scheduled time count as missed Jobs. When .spec.suspend changes\r\nfrom true to false on an existing CronJob without a starting deadline, the missed Jobs are scheduled\r\nimmediately.\r\nJobs history limits\r\nThe .spec.successfulJobsHistoryLimit and .spec.failedJobsHistoryLimit fields specify how many\r\ncompleted and failed Jobs should be kept. Both fields are optional.\r\n.spec.successfulJobsHistoryLimit : This field specifies the number of successful finished jobs to keep.\r\nThe default value is 3 . Setting this field to 0 will not keep any successful jobs.\r\n.spec.failedJobsHistoryLimit : This field specifies the number of failed finished jobs to keep. The\r\ndefault value is 1 . Setting this field to 0 will not keep any failed jobs.\r\nFor another way to clean up Jobs automatically, see Clean up finished Jobs automatically.\r\nTime zones\r\nFEATURE STATE: Kubernetes v1.27 [stable]\r\nFor CronJobs with no time zone specified, the kube-controller-manager interprets schedules relative to its local\r\ntime zone.\r\nYou can specify a time zone for a CronJob by setting .spec.timeZone to the name of a valid time zone. For\r\nexample, setting .spec.timeZone: \"Etc/UTC\" instructs Kubernetes to interpret the schedule relative to\r\nCoordinated Universal Time.\r\nA time zone database from the Go standard library is included in the binaries and used as a fallback in case an\r\nexternal database is not available on the system.\r\nCronJob limitations\r\nUnsupported TimeZone specification\r\nhttps://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/\r\nPage 4 of 6\n\nSpecifying a timezone using CRON_TZ or TZ variables inside .spec.schedule is not officially supported (and\r\nnever has been). If you try to set a schedule that includes TZ or CRON_TZ timezone specification, Kubernetes\r\nwill fail to create or update the resource with a validation error. You should specify time zones using the time zone\r\nfield, instead.\r\nModifying a CronJob\r\nBy design, a CronJob contains a template for new Jobs. If you modify an existing CronJob, the changes you make\r\nwill apply to new Jobs that start to run after your modification is complete. Jobs (and their Pods) that have already\r\nstarted continue to run without changes. That is, the CronJob does not update existing Jobs, even if those remain\r\nrunning.\r\nJob creation\r\nA CronJob creates a Job object approximately once per execution time of its schedule. The scheduling is\r\napproximate because there are certain circumstances where two Jobs might be created, or no Job might be created.\r\nKubernetes tries to avoid those situations, but does not completely prevent them. Therefore, the Jobs that you\r\ndefine should be idempotent.\r\nStarting with Kubernetes v1.32, CronJobs apply an annotation batch.kubernetes.io/cronjob-scheduled-timestamp to their created Jobs. This annotation indicates the originally scheduled creation time for the Job and is\r\nformatted in RFC3339.\r\nIf startingDeadlineSeconds is set to a large value or left unset (the default) and if concurrencyPolicy is set to\r\nAllow , the Jobs will always run at least once.\r\nCaution:\r\nIf startingDeadlineSeconds is set to a value less than 10 seconds, the CronJob may not be scheduled. This is\r\nbecause the CronJob controller checks things every 10 seconds.\r\nFor every CronJob, the CronJob Controller checks how many schedules it missed in the duration from its last\r\nscheduled time until now. If there are more than 100 missed schedules, then it does not start the Job and logs the\r\nerror.\r\ntoo many missed start times. Set or decrease .spec.startingDeadlineSeconds or check clock skew\r\nThis behavior is applicable for catch-up scheduling and does not mean the CronJob will stop running.\r\nFor example, when using concurrencyPolicy: Forbid , long-running Jobs may cause scheduled times to be\r\nskipped, but a new Job can be created once the previous Job completes.\r\nIt is important to note that if the startingDeadlineSeconds field is set (not nil ), the controller counts how\r\nmany missed Jobs occurred from the value of startingDeadlineSeconds until now rather than from the last\r\nhttps://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/\r\nPage 5 of 6\n\nscheduled time until now. For example, if startingDeadlineSeconds is 200 , the controller counts how many\r\nmissed Jobs occurred in the last 200 seconds.\r\nA CronJob is counted as missed if it has failed to be created at its scheduled time. For example, if\r\nconcurrencyPolicy is set to Forbid and a CronJob was attempted to be scheduled when there was a previous\r\nschedule still running, then it would count as missed.\r\nFor example, suppose a CronJob is set to schedule a new Job every one minute beginning at 08:30:00 , and its\r\nstartingDeadlineSeconds field is not set. If the CronJob controller happens to be down from 08:29:00 to\r\n10:21:00 , the Job will not start as the number of missed Jobs which missed their schedule is greater than 100.\r\nTo illustrate this concept further, suppose a CronJob is set to schedule a new Job every one minute beginning at\r\n08:30:00 , and its startingDeadlineSeconds is set to 200 seconds. If the CronJob controller happens to be\r\ndown for the same period as the previous example ( 08:29:00 to 10:21:00 ,) the Job will still start at 10:22:00.\r\nThis happens as the controller now checks how many missed schedules happened in the last 200 seconds (i.e., 3\r\nmissed schedules), rather than from the last scheduled time until now.\r\nThe CronJob is only responsible for creating Jobs that match its schedule, and the Job in turn is responsible for the\r\nmanagement of the Pods it represents.\r\nWhat's next\r\nLearn about Pods and Jobs, two concepts that CronJobs rely upon.\r\nRead about the detailed format of CronJob .spec.schedule fields.\r\nFor instructions on creating and working with CronJobs, and for an example of a CronJob manifest, see\r\nRunning automated tasks with CronJobs.\r\nCronJob is part of the Kubernetes REST API. Read the CronJob API reference for more details.\r\nSource: https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/\r\nhttps://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/" ], "report_names": [ "cron-jobs" ], "threat_actors": [ { "id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2", "created_at": "2022-10-25T16:07:24.471018Z", "updated_at": "2026-04-10T02:00:05.002374Z", "deleted_at": null, "main_name": "Cron", "aliases": [], "source_name": "ETDA:Cron", "tools": [ "Catelites", "Catelites Bot", "CronBot", "TinyZBot" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434543, "ts_updated_at": 1775826765, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/a11374479d4937e054cfab8e6ef25b4152a29ad7.pdf", "text": "https://archive.orkl.eu/a11374479d4937e054cfab8e6ef25b4152a29ad7.txt", "img": "https://archive.orkl.eu/a11374479d4937e054cfab8e6ef25b4152a29ad7.jpg" } }