Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.specific.dev/llms.txt

Use this file to discover all available pages before exploring further.

A job is a single execution of a user-supplied command inside a one-off container built from the currently-running service. The container uses the same image, environment variables, and resources as the service’s live Kubernetes Deployment — only the command is different. Jobs are the remote equivalent of specific exec. Where specific exec runs a one-off command against your local dev environment, a Job runs against the deployed service in production (or any other environment). Use them for ad-hoc, on-demand work such as:
  • One-off data backfills or corrections.
  • Reconciling state, purging a cache, or replaying a queue.
  • Running a debugging or diagnostic script against production data.
Don’t use Jobs for database migrations. Migrations should run in a pre_deploy hook so they’re tied to the deployment lifecycle: the hook runs before the new service version starts, and if it fails, the deployment is automatically aborted before any traffic reaches the new code. Jobs are decoupled from deployments and have no such safety net.

​
Running a job

Open the Specific dashboard, navigate to a service, and open the Jobs tab. Click Run job, fill in an optional name and a command, and submit. You will be redirected to the job’s detail page, where you can watch its state update and stream logs in real time. Re-running a previous job pre-fills the modal with its name and command — a convenient way to replay a migration after fixing a bug, for example.

​
Lifecycle

A job transitions through the following states:
  1. pending — the job has been recorded in the database.
  2. queued — the Temporal workflow has been started.
  3. running — the Kubernetes Job is running.
  4. One of:
    • succeeded — the command exited with code 0.
    • failed — the command exited with a non-zero code, or the underlying infrastructure rejected the job.
    • cancelled — the job was cancelled via the dashboard before it finished.

​
How it works

When you start a Job, Specific reads the live Kubernetes Deployment for the target service and copies its pod template: image, env/envFrom references, resources, volumes, and service account. The only changes are:
  • The command is replaced with sh -c "<your command>".
  • Serving-only fields (ports, probes, preStop lifecycle) are stripped.
  • restartPolicy is Never and backoffLimit is 0 — a Job runs exactly once.
This means Jobs always see the same secrets, configs, and resource bindings as the running service — no drift between what you test against in the service and what runs in the Job.

​
Caveats

  • The service must be deployed. A Job reads the service’s Kubernetes Deployment to build its container spec. If the service has never been deployed, the Job will fail with a clear error.
  • No retries on failure. If the command exits non-zero, the Job is marked failed. Start a new Job (or Re-run) to try again.
  • Single container only. If the service has sidecars or init containers, they are not replicated into the Job — only the primary container runs.
  • Concurrent Jobs are allowed. Multiple Jobs can run at the same time against the same service. Be mindful of shared state (e.g. long-lived migrations running in parallel).
  • PVC contention. If the service mounts a ReadWriteOnce volume and is running on a different node than the Job pod, the Job will fail to schedule.
  • The Kubernetes Job is cleaned up 1 hour after completion. Logs remain in ClickHouse for the standard retention window.