Application detail & logs
The managed resource tree grouped by type, the app’s Kubernetes events, and streaming pod logs that bookmark the workload rather than the pod.
Tapping an application opens a page built from ArgoCD’s own view of it — no Kubernetes connection required, because ArgoCD already knows.
Summary and resource tree
A header summarises sync status, health, project, destination and revision. Below it, the
application’s managed resources — from the /resource-tree endpoint — grouped by kind,
each row showing:
- health and sync state,
- age,
- container images,
- ArgoCD’s own “info” facts for that resource.
This is the fastest way to answer “which part of the app is unhealthy” — the Deployment, its ReplicaSet, one Pod, a Service, a ConfigMap.
Events
The app’s Kubernetes events, from ArgoCD’s /events endpoint, so the reason a resource is
Degraded is on the same screen as the resource.
Logs
Any Pod row streams its logs, through ArgoCD’s logs endpoint, in the same viewer the Kubernetes log screens use — line filter, match count, auto-scroll pause, compact JSON, copy-visible.
Bookmarks that outlive the pod
The star on an ArgoCD logs page does something more useful than bookmarking a URL: it walks
the resource tree’s parentRefs up to the owning workload (Deployment, DaemonSet, Job)
and bookmarks that.
Opening the bookmark later streams the merged logs of every pod the workload currently owns — ArgoCD’s logs endpoint in resource mode, with each line tagged by pod — so it covers all replicas and survives pod churn. If the workload has no pods right now, it says so.
A pod name from last Tuesday is worthless. A workload is not.
The per-pod “View logs” button stays single-pod, for when that is what you actually want.
Back to ArgoCD.