Overview
CronJob Guardian supports monitoring CronJobs across namespace boundaries. This is useful for:- Platform teams monitoring critical jobs across all applications
- Multi-tenant clusters with centralized monitoring
- Monitoring staging and production environments together
Monitor Multiple Specific Namespaces
Explicitly list the namespaces you want to monitor.monitors/multi-namespace.yaml
What This Does
- Monitors CronJobs in
production,staging, anddata-pipelinenamespaces - Only watches jobs with label
tier: criticalin those namespaces - The monitor itself lives in
cronjob-guardiannamespace - All matching jobs share the same monitoring configuration
Setup Instructions
Ensure proper permissions
The CronJob Guardian controller needs RBAC permissions to watch CronJobs across namespaces. The default installation includes cluster-wide permissions.Verify the controller can access the namespaces:
Monitor Namespaces by Label
Dynamically discover namespaces based on their labels. This is powerful for automated environments.monitors/namespace-selector.yaml
What This Does
- Discovers all namespaces with label
environment: production - Within those namespaces, monitors CronJobs with label
monitored: "true" - Automatically picks up new namespaces when they’re created with the right label
- Perfect for dynamic environments with auto-provisioned namespaces
Setup Instructions
Cluster-Wide Monitoring
For platform teams, monitor all CronJobs across the entire cluster.monitors/cluster-wide.yaml
What This Does
- Monitors every CronJob in every namespace (if they have
tier: criticallabel) - Sends critical alerts to PagerDuty for on-call escalation
- Sends all alerts to Slack for visibility
- Provides a single pane of glass for all critical jobs
When to Use This
- Platform/SRE teams responsible for all infrastructure
- Small to medium clusters where monitoring everything is manageable
- When you have a clear labeling standard (e.g.,
tier: critical)
Setup Instructions
Comparison of Approaches
Explicit Namespaces vs. Namespace Selector
Explicit Namespaces vs. Namespace Selector
Explicit Namespaces (
namespaces: [prod, staging]):- Simple and explicit
- Requires updating the monitor when adding namespaces
- Best for static environments with few namespaces
namespaceSelector):- Dynamic and automated
- New namespaces automatically picked up
- Best for dynamic environments (multi-tenant, auto-scaling)
Multi-Namespace vs. Multiple Single-Namespace Monitors
Multi-Namespace vs. Multiple Single-Namespace Monitors
Single Multi-Namespace Monitor:
- One configuration for all namespaces
- Same SLA and alert rules everywhere
- Simpler to manage at scale
- Different SLA/alert rules per namespace
- More granular control
- More YAML to maintain
Cluster-Wide vs. Targeted Monitoring
Cluster-Wide vs. Targeted Monitoring
Cluster-Wide:
- One monitor to rule them all
- Simple for small/medium clusters
- Risk of alert fatigue
- More control and less noise
- Better for large clusters
- Requires more planning
Advanced Filtering Techniques
Combine multiple selector types for precise control:- Only namespaces with
environment: production - Only jobs with
tier: criticalortier: high - Excludes jobs with a
monitoringlabel (opt-out mechanism)
Next Steps
Cluster-Wide Examples
More cluster-wide monitoring patterns
Advanced Features
SLA tracking and regression detection
Alert Routing
Route alerts to different channels by severity
RBAC Configuration
Set up permissions for cross-namespace monitoring