Your Renovate CronJob Is Probably Broken Right Now

The Visibility Gap in Platform Engineering

Here's a question most platform engineers can't answer confidently: of all the repositories in your organization, how many actually had a successful Renovate scan this week?

​

If you're running Renovate via CronJobs — which is the most common self-hosted setup — the honest answer is probably "I don't know." CronJobs don't give you visibility. They don't tell you when a scan was skipped because of a resource conflict; they don't alert you when a secret expired and every job silently started failing. They definitely don't show you which of your 150 repos have been drifting for three months.

​

The mogenius Renovate Operator replaces this entire setup with a Kubernetes-native operator. You define update policies as CRDs, the operator handles scheduling and execution, and you get a web dashboard that shows what's actually happening.

​

What Renovate Does and Where It Falls Short

Renovate by Mend is the engine. It scans your repos for outdated dependencies: npm packages, Go modules, Helm chart versions, Docker image tags, Kustomize bases, and Terraform providers. It then opens PRs with the updates. It supports grouping, automerge rules, and scheduling. It's excellent at what it does.

​

The problem isn't the engine; it is the deployment model.

​

Running Renovate via the CLI or a basic CronJob means you're managing scheduling, secret injection, resource limits, and failure handling yourself. At 5 repos, this is fine. At 50, it's tedious. At 200+, it's a maintenance burden that generates exactly the kind of operational toil Renovate was supposed to eliminate.

​

The Mend Community Edition (CE) improves on this, but it runs as a single container with limited observability and no Kubernetes-native integration. There are no CRDs, no RBAC, and no Prometheus metrics.

​

The Operator Approach: CRDs Instead of CronJobs

The Renovate Operator (MIT licensed) treats dependency management as a first-class Kubernetes workload. Instead of a CronJob manifest, you define a CRD:

This gives you features that CronJobs cannot provide:

​

• Schema validation at apply time: If you typo a field or use an invalid value, kubectl apply rejects it immediately. Config errors are no longer discovered at 2 AM when the job runs.
• RBAC integration: Control who can create or modify update policies through standard Kubernetes role bindings. Your dependency governance uses the same access model as everything else in the cluster.
• Status tracking: The CRD status reflects the actual state of each project: scheduled, running, completed, or failed. Query it with kubectl get renovate like any other resource.

​

Architecture: How the Three Components Work Together

The operator runs three components in a control loop:

​

1. The Controller watches Renovate CRDs and manages scheduling. It reconciles every 60 seconds, syncing desired state with actual state.
2. The Discovery Agent eliminates manual onboarding. Enable -autodiscover and it crawls your GitHub, GitLab, Bitbucket, Azure DevOps, Gitea, or Forgejo organizations to find all repos and register them. New repos are picked up automatically on the next cycle.
3. The Executor Loop runs every 10 seconds, picking up scheduled projects and spawning Kubernetes batch jobs. It strictly respects spec.parallelism. If you set it to 3, only 3 Renovate jobs run concurrently. This prevents the API rate-limiting issues that hit teams running dozens of CronJobs simultaneously.

​

Installation: Helm, Five Minutes

The fastest path to deployment:

Or via the Helm repository:

The current version is 3.2.1. The chart is also available on Artifact Hub.

​

Benefits Beyond Standard CronJobs

• Web Dashboard: A built-in UI shows all discovered projects, their scan status, execution history, and logs. This is the single biggest operational improvement: you can actually see what's happening.
• Prometheus Metrics: The operator exposes metrics endpoints for your monitoring stack. Track scan success rates, execution times, and job queue depth.
• Webhook Support: Configure GitHub or GitLab webhooks to trigger on-demand scans, useful for running Renovate immediately after a new release.
• Leader Election: For HA deployments, the operator supports leader election. If the active pod goes down, a standby takes over without losing job state.
• Health Checks: Liveness and readiness probes are built in to ensure cluster self-healing works as expected.

​

Security and Platform Support

The operator ships with sensible security out of the box. All worker jobs run as non-root with RuntimeDefault seccomp profiles. Resource requests and limits are set on every job, preventing scans from starving production workloads. Git credentials are stored as Kubernetes Secrets and never leave the cluster. For teams using HashiCorp Vault or AWS Secrets Manager, it supports the External Secrets Operator.

​

When to use this over other options: Use the Renovate Operator if you are running Kubernetes, managing more than a handful of repositories, and want CRD-based configuration with native monitoring. Stick with CronJobs if you have fewer than 10 repos and don't need visibility.

​

Resources:

• Renovate Operator on GitHub
• mogenius Platform
• Professional Services for Kubernetes

​