Introduction

Yes, you can monitor Kubernetes CronJobs with Prometheus, and the usual foundation is kube-state-metrics. It exposes CronJob and Job state from the Kubernetes API, which lets Prometheus answer questions such as "Was this CronJob scheduled?", "Is it suspended?", "Does it currently have active runs?", and "Did the Jobs it created fail?"

What Prometheus can and cannot tell you

There are two levels of monitoring for CronJobs:

1. Controller-level monitoring: did Kubernetes schedule and run the Job objects correctly?
2. Workload-level monitoring: did the actual batch task succeed logically?

kube-state-metrics is great for the first category. It exposes the state of CronJobs, Jobs, and Pods. It does not know whether your backup file was valid or whether your ETL produced correct business results. For that, the job itself should emit an application-level success signal.

Start with kube-state-metrics

In most Kubernetes monitoring stacks, Prometheus already scrapes kube-state-metrics. If not, add it and make sure Prometheus discovers its /metrics endpoint.

A minimal scrape config looks like this:

1scrape_configs:
2  - job_name: kube-state-metrics
3    static_configs:
4      - targets:
5          - kube-state-metrics.kube-system.svc.cluster.local:8080

Once that is being scraped, CronJob-related metrics are available for PromQL queries and alert rules.

Useful CronJob and Job metrics

Some of the most useful series are:

• 'kube_cronjob_status_last_schedule_time'
• 'kube_cronjob_next_schedule_time'
• 'kube_cronjob_status_active'
• 'kube_cronjob_spec_suspend'
• 'kube_job_status_succeeded'
• 'kube_job_status_failed'
• 'kube_job_owner'

The CronJob metrics tell you about the scheduler/controller state. The Job metrics tell you about the concrete Jobs created by the CronJob. kube_job_owner is particularly helpful because it lets you join Jobs back to the owning CronJob.

Example PromQL queries

Find CronJobs that are currently suspended:

kube_cronjob_spec_suspend == 1

Find CronJobs that still have active Jobs:

kube_cronjob_status_active > 0

A simple overdue-schedule style alert can be approximated with:

time() > kube_cronjob_next_schedule_time + 300
and kube_cronjob_spec_suspend == 0

The extra 300 seconds is a grace window. Tune it to your environment because controller latency, clock skew, and job startup time all matter.

To find failed Jobs owned by CronJobs:

kube_job_status_failed > 0
  * on(namespace, job_name) group_left(owner_name)
    kube_job_owner{owner_kind="CronJob"}

That gives you failed Jobs and carries over the owning CronJob name through the owner_name label.

Example alert rule

A simple alert for CronJob-backed Job failures might look like this:

1groups:
2  - name: cronjob.rules
3    rules:
4      - alert: CronJobJobFailed
5        expr: |
6          kube_job_status_failed > 0
7            * on(namespace, job_name) group_left(owner_name)
8              kube_job_owner{owner_kind="CronJob"}
9        for: 5m
10        labels:
11          severity: warning
12        annotations:
13          summary: "CronJob job failed"
14          description: "A Job created by CronJob {{ $labels.owner_name }} failed in namespace {{ $labels.namespace }}."

That is a good start, but production monitoring usually adds job-specific thresholds and routing rules.

For short-lived jobs, add an application success signal

CronJobs are short-lived, so relying only on pod scraping can be unreliable. A batch job may start and finish between Prometheus scrapes. That is why controller-state metrics from kube-state-metrics are useful.

But they still do not tell you whether the job's business logic succeeded. For important batch pipelines, add a metric such as job_last_success_unixtime or job_records_processed_total from the job itself and publish it somewhere durable. Some teams use Pushgateway for this pattern, but it should be used deliberately and cleaned up carefully.

Common Pitfalls

The biggest mistake is expecting Prometheus to infer business success from Kubernetes state alone. A Job can complete successfully while still producing bad output.

Another issue is alerting on schedule timing without a per-job grace window. Some CronJobs run hourly, some daily, and some have controller or startup delays, so one universal threshold creates noise.

Developers also forget to join Job metrics back to CronJobs. Without kube_job_owner, Job failures can be hard to attribute in alerts.

Finally, label names can vary slightly across kube-state-metrics versions, so validate your exact metric output in /metrics before finalizing rules.

Summary

• Yes, Prometheus can monitor CronJobs, usually through kube-state-metrics.
• Use CronJob metrics for scheduling state and Job metrics for concrete execution outcomes.
• Join Job metrics back to CronJobs with kube_job_owner.
• Add application-level success metrics for important batch jobs because Kubernetes state is not the same as business success.
• Build alerts with realistic grace windows and verify metric names against your installed kube-state-metrics version.