Skip to main content
Kubernetes Jobs in Skyhook handle one-time and scheduled batch workloads using native Kubernetes Job and CronJob resources. They’re ideal for standalone, single-container tasks that run to completion without requiring multi-step orchestration or dependencies between steps.

​
Job Types

Skyhook supports two Kubernetes job types:

Kubernetes Job

One-time executionSingle-container tasks that run once and exit. Best for standalone operations like migrations, data imports, and one-off scripts.

Kubernetes CronJob

Scheduled tasksRecurring single-container jobs on cron schedule with timezone support. Best for backups, cleanups, and regular maintenance.

​
Kubernetes Job

Key features:
  • Deploy & Run - Single button that deploys job manifest and triggers immediate execution
  • Built-in retry mechanisms - Automatic pod restart on failure
  • Automatic resource cleanup - TTL-based pod cleanup after completion
  • Pod parallelism - Run multiple pods concurrently for the same job
  • Completion tracking - Kubernetes tracks job completion status

​
Kubernetes CronJob

Key features:
  • Cron schedule syntax - Standard cron expressions (e.g., 0 2 * * * for daily at 2 AM)
  • Timezone support - Schedule in local timezone, not just UTC
  • Concurrency policies - Prevent overlapping runs (Allow, Forbid, Replace)
  • Job history retention - Configure how many completed jobs to keep
  • Manual trigger - Execute immediately outside schedule with “Run Now”

​
Creating a Job

​
1. Access the Job Creation Form

  1. Navigate to Jobs in the Skyhook UI
  2. Click Create New Job
  3. The job creation form appears with multiple configuration sections
Job Creation Form

​
2. Basic Details

Configure your job’s fundamental properties: Job Name
  • Must be lowercase with no spaces
  • Use hyphens for multi-word names (e.g., daily-data-sync)
  • Must be unique within your organization
Description (optional)
  • Brief explanation of the job’s purpose
  • Helps team members understand the job’s function
Container Registry
  • Select where your Docker images will be stored
  • Supports ECR, GCR, GHCR, Docker Hub, and custom registries
  • Format varies by provider:
    • AWS ECR: 123456789.dkr.ecr.us-east-1.amazonaws.com
    • GCP Artifact Registry: us-docker.pkg.dev/project-id/repository
    • GHCR: ghcr.io/organization

​
3. Repository Configuration

Choose how to set up your job’s code repository: Option A: Create New Repository
  • Skyhook creates a new Git repository for your job
  • Initializes with basic job structure
  • Best for brand new jobs
Option B: Use Existing Repository (Multiple Jobs/Services) Option C: Import Existing Repository
  • Connect an existing repository containing job code
  • Provide repository URL and path
  • Skyhook configures CI/CD for the existing code
Deployment Repository: You’ll also choose where to store Kubernetes manifests and deployment configuration:
  • Keep in job repository - Deployment files alongside code (simpler)
  • Create separate deployment repository - Dedicated repo for configs
  • Use existing deployment repository - Add to centralized deployment repo
Learn more about Deployment Repository Options

​
4. Select Job Type

Choose between Kubernetes Job (one-time), Kubernetes CronJob (scheduled), Argo Workflow, or Argo CronWorkflow. The dropdown displays each job type with a description to help you choose the right option for your use case.

​
5. Cron Configuration (CronJob only)

When you select CronJob, additional scheduling options appear:
Cron Configuration Options
Cron Schedule (required)
  • Standard 5-field cron expression: minute hour day month weekday
  • Examples:
    • 0 2 * * * - Every day at 2:00 AM
    • 0 */6 * * * - Every 6 hours
    • 0 0 * * 0 - Every Sunday at midnight
    • 30 14 1 * * - At 2:30 PM on the first day of each month
  • Shortcuts:
    • @hourly - Run every hour
    • @daily or @midnight - Run daily at midnight
    • @weekly - Run weekly on Sunday at midnight
    • @monthly - Run monthly on the first at midnight
Timezone (optional, defaults to UTC)
  • Select from searchable dropdown of all IANA timezones
  • UI displays current UTC offset for each timezone (e.g., America/New_York (GMT-5))
  • Ensures schedule runs at the correct local time regardless of DST changes
Concurrency Policy (optional, defaults to Allow)
  • Allow - Allow concurrent executions (jobs can overlap)
  • Forbid - Skip new run if previous is still running
  • Replace - Cancel previous run and start new one
Starting Deadline Seconds (optional)
  • Maximum seconds to start a missed job
  • If job misses its schedule and this deadline passes, skip it
  • Useful for preventing backlog of missed jobs
Successful Jobs History Limit (optional, default 30)
  • Number of successful job pods to retain
  • Older successful jobs are automatically cleaned up
  • Recommended: 3-30 depending on debugging needs
Failed Jobs History Limit (optional, default 30)
  • Number of failed job pods to retain
  • Keep failed jobs longer for debugging
  • Recommended: 1-30 depending on failure frequency

​
6. Add Environments

Configure where your job will run:
  1. Click Add Environment
  2. For each environment, provide:
    • Name - Environment identifier (dev, staging, prod, etc.)
    • Namespace - Kubernetes namespace (must exist in cluster)
    • Cluster - Select from available clusters in your organization
  3. Add multiple environments as needed

​
7. Submit and Create

  1. Review all configuration
  2. Click Create Job
  3. Skyhook creates the job and redirects to the job detail page

​
Executing Jobs

  • Kubernetes Job
  • Kubernetes CronJob

Deploy & Run in one action

Kubernetes Jobs combine deployment and execution in a single action.To execute:
  1. Navigate to your job’s detail page
  2. Click Deploy & Run
  3. Configure deployment options:
    • Build new image or deploy existing image
    • Select Git code reference (branch, tag, commit)
    • Choose config reference for Kubernetes manifests
    • Pick target environment
  4. Review deployment summary
  5. Click Deploy
What happens:
  • GitHub Actions workflow builds image (if needed)
  • Deploys job manifest to cluster
  • Job immediately creates pod(s) and starts execution
  • Job runs to completion
  • Pod cleanup after TTL expiration
Execution tracking:
  • View workflow progress via GitHub Actions link
  • Monitor job status on Executions tab
  • Check pod logs once running

​
Monitoring Executions

​
Executions Tab

The Executions tab provides a comprehensive view of all job runs. Access:
  1. Navigate to job detail page
  2. Click Executions tab
Job Executions Tab
What you see:
  • List of all job instances/executions
  • Status for each execution (Running, Succeeded, Failed, Pending)
  • Start time, completion time, duration
  • Environment where job ran
  • Filter and search capabilities
Filters:
  • By environment (dev, staging, prod)
  • By status (succeeded, failed, running)
  • By job name (search/filter)
  • Date range (recent executions)

​
Execution Status

Jobs display different statuses throughout their lifecycle:
StatusDescriptionIndicates
🟡 PendingJob created but not yet runningWaiting for resources or schedule
🔵 RunningJob currently executingPods are active and processing
✅ SucceededJob completed successfullyAll pods finished with exit code 0
❌ FailedJob did not complete successfullyPods failed or retry limit exceeded
⚪ UnknownStatus cannot be determinedPossible connectivity issues

​
Job Details

Execution details show: Pod Information:
  • Active Pods - Currently running
  • Succeeded Pods - Completed successfully
  • Failed Pods - Terminated with errors
Job Specifications:
  • Completions required
  • Parallelism (concurrent pods)
  • Restart policy
  • Active deadline
Timing:
  • Start time
  • Completion time (when finished)
  • Duration (total execution time)
Actions:
  • View pod logs
  • Inspect pod details
  • Download logs

​
Viewing Logs

Access Pod Logs:
  1. Click on a job execution in the list
  2. Expand pod details
  3. Click View Logs
  4. Logs display in real-time

​
Managing Your Job

The job detail page provides everything you need to manage your job through the Skyhook UI: General Tab
  • View basic details and cron schedule (for CronJobs)
  • See next run time and recent execution history
  • Quick status overview with badges
Environments Tab
  • Add, edit, or remove environments
  • Update cluster and namespace assignments
  • Environment-specific configuration
Env Vars & Secrets Tab
  • Set global variables (shared across all environments)
  • Configure environment-specific variables
  • Manage encrypted secrets (integrated with Sealed Secrets)
Settings Tab
  • Update execution settings (active deadline, retry strategy)
  • Configure resource limits (CPU, memory)
  • Adjust history retention limits (for CronJobs)
For advanced users, Skyhook uses Kustomize to manage job configurations. Jobs are stored in Git with environment-specific overrides:
my-job/
├── base/
│   ├── job.yaml           # Job or CronJob definition
│   └── kustomization.yaml
│
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml
    │   ├── job-patch.yaml          # Dev-specific overrides
    │   └── .env
    │
    └── prod/
        ├── kustomization.yaml
        ├── job-patch.yaml          # Prod-specific overrides
        └── .env
Base configuration defines the core job specification (container image, command, resources).Environment overlays provide environment-specific customizations (different resources, schedules, env vars per environment).You can edit these files directly in your Git repository for advanced configuration not available in the UI.

​
Common Tasks

Change CronJob Schedule

  1. Go to Settings tab
  2. Update cron schedule expression
  3. Optionally update timezone
  4. Click Save
  5. Deploy changes to environments

Add Environment Variables

  1. Navigate to Env Vars & Secrets tab
  2. Click Add
  3. Choose variable type (global, environment-specific, or secret)
  4. Enter key and value
  5. Click Save
  6. Redeploy job to apply

Update Resource Limits

  1. Go to Settings → Execution section
  2. Update CPU or memory limits
  3. Click Save
  4. Redeploy to environment

Pause a CronJob

UI support for pausing CronJobs is coming soon.
For now, use kubectl:
kubectl patch cronjob my-job -n namespace -p '{"spec":{"suspend":true}}'
To resume, set suspend to false.

​
Best Practices

Scheduling (for CronJobs):
  • Use timezone-aware schedules to avoid DST issues
  • Use Forbid concurrency policy for jobs that shouldn’t overlap
  • Adjust history limits from defaults (30 each) based on debugging needs and storage capacity
  • Test cron expressions before deploying: crontab.guru
Resource Management:
  • Set active deadlines to prevent runaway jobs
  • Configure resource limits based on actual usage
  • Use more resources in production than dev
  • Monitor execution duration trends and adjust
Security:
  • Always use secrets (not env vars) for sensitive data
  • Rotate secrets regularly
  • Use different secrets per environment
  • Never hardcode credentials in code or manifests