Skip to main content
Radar treats batch workloads differently from long-running services. A Deployment is usually understood through readiness and replicas. A Job or workflow is understood through its runs: what launched each run, what it executed, whether it completed, and where it failed. Open a Job-class workload from Applications to inspect its retained runs. Radar supports Kubernetes Jobs and CronJobs, Argo Workflows, CronWorkflows, WorkflowTemplates and ClusterWorkflowTemplates, and KEDA ScaledJobs.
Run history comes from objects still retained in Kubernetes. It is not durable or all-time execution history.

​
Definition, run, and execution

Radar separates three concepts that Kubernetes and workflow controllers often present together:
  • Definition or scheduler - the Job, CronJob, WorkflowTemplate, CronWorkflow, or ScaledJob that describes or launches work.
  • Run - one concrete Job or Workflow created from that definition.
  • Execution - the Pods, Argo steps, DAG tasks, retries, and fan-out items inside the selected run.
The retained-run rail on the left belongs to the definition or scheduler. Selecting a run updates the Overview and Logs tabs together, so every diagnostic surface stays focused on the same execution.
Radar showing an Argo WorkflowTemplate with a retained-run rail, selected run details, current definition, DAG execution tree, inputs, and run activity

​
Understand what ran

The selected-run card shows timing, progress, Pod outcomes, execution-node outcomes, and resource duration. Run configuration describes the configuration captured for that run, while Current definition shows what the definition contains now. Radar surfaces the operational fields most useful during diagnosis:
  • container images, commands, and arguments
  • CPU and memory requests and limits
  • retry, deadline, parallelism, and completion settings
  • service account, ConfigMaps, and Secrets
  • workflow entrypoint, template references, and input parameters
If those summarized execution fields differ, Radar marks the run as different from the current definition. This helps explain failures caused by an older image, command, input, or resource configuration without implying a full object diff.

​
Follow Argo execution

For Argo Workflows, Run execution converts controller bookkeeping into a readable hierarchy. It preserves authored task and step names while representing:
  • sequential and parallel Steps
  • DAG tasks and fan-out items
  • retries and attempts
  • nested templates and template references
  • skipped, suspended, HTTP, plugin, and ContainerSet work
Generated singleton groups such as [0] are omitted when they add no meaning. A fan-out remains grouped, and each item is labeled with its run position or parsed item value where available. The Overview is an execution tree optimized for diagnosis, not a complete dependency graph. DAG join relationships are preserved in the underlying workflow data but are not rendered as multi-parent graph edges in this view.

​
Diagnose a failed run

Start with the failed row in Run execution, then use Failure details, Run activity, Logs, or Timeline:
  1. Select a failed run from the retained-run rail.
  2. Find the failed step, task, retry, or Pod under Run execution.
  3. Expand Failure details when the controller message needs more room.
  4. Open Logs when the run still has a retained Pod.
  5. Use Timeline to inspect related resource activity across the workload and its runs.
Radar showing a failed Argo Workflow run, its captured image, failure details, failed execution node, run activity, and a View timeline action because the Pod is no longer retained
Kubernetes serves container logs through the Pod. If a terminal run remains but its Pod has already been deleted, Radar does not offer a Logs action that cannot work. The failure view explains that the logs are no longer available and points to Timeline or your external log archive instead.

​
Scheduled workloads

CronJobs, CronWorkflows, and ScaledJobs use the same run-focused model. The scheduler remains the stable workload, while generated Jobs or Workflows appear as retained runs rather than duplicate applications. The schedule card includes controller-specific settings such as schedule, timezone, concurrency policy, suspension, deadlines, retention limits, and referenced templates where applicable.

​
See also

  • Applications - browse workloads grouped into applications.
  • Argo Workflows - supported Argo resources and integration details.
  • KEDA - ScaledJob and ScaledObject visibility.
  • Timeline - inspect retained Kubernetes activity across a workload.