Monitor Kubernetes CronJobs SigNoz has released a guide for monitoring Kubernetes CronJobs using its `k8s-infra` OpenTelemetry collection agent, which automatically captures pod logs and Job metrics without requiring extra configuration. The guide demonstrates creating a sample CronJob and validating telemetry data in SigNoz's Logs and Metrics Explorers, enabling users to track execution history and diagnose failures. This guide shows you how to monitor Kubernetes CronJobs with the SigNoz k8s-infra OpenTelemetry collection agent. Prerequisites k8s-infra is already installed in your cluster. If you have not installed it yet, follow Install K8s Infra https://signoz.io/docs/opentelemetry-collection-agents/k8s/k8s-infra/install-k8s-infra/ .- You have kubectl access to the cluster where your CronJobs run. - You have a SigNoz backend available to receive telemetry. If you already have CronJobs running in your cluster, you can skip Step 1 and Step 2 and go directly to Default telemetry from and k8s-infra . Validate validate Step 1. Create a CronJob Apply the following manifest to create a CronJob that runs every minute and writes logs to standard output: apiVersion: v1 kind: Namespace metadata: name: batch-jobs --- apiVersion: batch/v1 kind: CronJob metadata: name: reporting-demo namespace: batch-jobs labels: app.kubernetes.io/name: reporting-demo spec: schedule: " /1 " timeZone: "Etc/UTC" concurrencyPolicy: Forbid successfulJobsHistoryLimit: 3 failedJobsHistoryLimit: 1 jobTemplate: spec: template: metadata: labels: app.kubernetes.io/name: reporting-demo spec: restartPolicy: OnFailure containers: - name: reporter image: busybox:1.36 command: - /bin/sh - -c - | echo "cronjob=reporting-demo start=$ date -Iseconds " sleep 5 echo "cronjob=reporting-demo finished=$ date -Iseconds " This example keeps the CronJob simple but still uses a few Kubernetes defaults that are useful for production: timeZone : Makes the schedule explicit instead of relying on the controller's local time zone concurrencyPolicy: Forbid : Prevents overlapping runs successfulJobsHistoryLimit and failedJobsHistoryLimit : Keeps recent execution history available for debugging Apply it: kubectl apply -f cronjob-demo.yaml Step 2. Wait for the first execution Check that Kubernetes creates a Job and a Pod for the CronJob: kubectl -n batch-jobs get cronjob,jobs,pods You should see: - The reporting-demo CronJob - A Job created from that CronJob - A completed Pod for that Job after the run finishes Want to see this CronJob in a single pre-built view? Skip to Visualize with the prebuilt dashboard visualize-with-the-prebuilt-dashboard once a few runs have completed. Default telemetry from k8s-infra No extra CronJob-specific Helm values are required for the default monitoring flow. If k8s-infra is already installed with metrics and logs collection enabled, it automatically collects CronJob pod logs and Kubernetes Job metrics when the CronJob runs. Default logs All logs emitted by CronJob pods are captured automatically in Logs Explorer with Kubernetes resource attributes such as: k8s.namespace.name k8s.cronjob.name k8s.job.name k8s.pod.name Use: k8s.cronjob.name to see all executions for one CronJob k8s.job.name to inspect one specific execution Default metrics In the validated k8s-infra setup for this guide, these CronJob-related Kubernetes metrics were emitted by default: k8s.cronjob.active jobs k8s.job.active pods k8s.job.successful pods k8s.job.failed pods k8s.job.desired successful pods k8s.job.max parallel pods These metrics come from the OpenTelemetry k8sclusterreceiver https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/k8sclusterreceiver/documentation.md . They are attached to Kubernetes Job resources, so k8s.job.name is the main dimension to use when you want to inspect one CronJob run in Metrics Explorer . Validate Validate logs in SigNoz Open Logs Explorer and filter with these resource attributes: k8s.cluster.name =