Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.

Lifecycle Watch - Ephemeral and Deleted Resources

Lifecycle Watch scans the inventory history of your clusters over a chosen time window and flags pods, PVCs, and buckets that were deleted, lived only briefly (ephemeral), or were destroyed and re-spawned under a new identity (recreated). Ephemeral and disappearing resources can signal reconnaissance, data exfiltration, attacker cleanup, or data loss, so this view makes them easy to spot instead of leaving them buried in the live topology.

Where: Data Security Posture > K8 inventory · lifecycle security

For the page layout, controls, and deep links, see Lifecycle Watch. This page explains each classification and how to review it.

Overview​

A single time-range selector drives the whole page. Changing the range or the ephemeral threshold re-runs the scan. The page compares inventory snapshots across the window to decide how each resource changed:

  • Deleted — the resource existed during the window but stopped appearing in inventory.
  • Ephemeral — the resource lived for less than the configurable threshold before being destroyed.
  • Recreated — a workload with the same name and owner came back under a new UID, for example after a redeploy, crash-loop, or re-spawn.

Three threat tiles show the totals for Deleted, Ephemeral, and Recreated, and three section cards below them list the matching resources.

Time range and threshold​

  • Range — Last 24h, Last 48h, Last 7d, or Last 30d. A wider range covers more history but takes longer to compute.
  • Ephemeral ≤ (min) — the lifespan threshold in minutes (default 120, range 1 to 1440). Lower it to focus on very short-lived resources, or raise it to catch resources that lived a little longer.

The header shows the active window, the ephemeral threshold, and when the last scan ran. Snapshots are stored fleet-wide, so selecting a single cluster does not filter the sections. See Cluster scope.

Lifecycle sections​

Each section is a card with a resource-type filter (Pods, PVCs, Buckets) that shows live counts. Click a type to switch the table. Sections show only the types that apply to them.

SectionApplies toContents
Deleted resourcesPods, PVCs, bucketsResources that vanished from inventory in the window. Columns: namespace (or device, for buckets), resource name, first seen, last seen, and lifespan. A name tagged ✕ <user> means the deletion is attributed to that user.
Ephemeral resourcesPods, PVCsShort-lived resources. The columns match Deleted, and every row has a lifespan under the threshold.
Recreated / churnedPodsAn incarnations count such as 4× instead of timestamps, showing how many times the same workload name reappeared under a new UID. High counts point to crash-loops or repeated re-spawns.

A table row can also show a short pod UID fragment after the pod name so you can trace a pod across recreations. Empty sections show a message such as "No deleted pods in the last 24h". If the query fails, an error banner appears above the sections.

Secondary tools​

The Snapshot Timeline and Pod Lifecycle Search panels are collapsed by default.

  • Snapshot Timeline — the point-in-time inventory captures. To compare two of them, pin two rows. See Inventory - Snapshot Timeline and Snapshot Diff.
  • Pod Lifecycle Search — a targeted, per-pod lookup of first-seen, last-seen, and duration. It complements the window-wide Deleted and Ephemeral sections. See Pod Lifecycle Search.

Workflows​

Spot short-lived pods that may indicate reconnaissance or exfiltration​

  1. Set Range to Last 24h, or wider if you are reviewing an incident over several days.
  2. Lower Ephemeral ≤ to a tight value such as 5 minutes.
  3. Read the Ephemeral tile and section. Every listed pod or PVC lived under your threshold, so check the namespace and name for anything unexpected.

Confirm what a deleted workload was and who removed it​

  1. Open the Deleted resources section and select Pods.
  2. Look for the ✕ <user> tag on a row to see who the deletion is attributed to.
  3. For a before-and-after comparison, expand Snapshot Timeline (see Secondary tools), pin one snapshot from before the deletion and one from after, and read the Removed pods and Removed PVCs columns in the diff drawer.

Tips​

  • Deletion and lifespan granularity is bounded by how often K8 scans run and by the Snapshot Frequency setting. A resource that appeared and disappeared between two scans may be reported with an approximate lifespan, and a very fast pod can be missed if it never landed in a snapshot.
  • Snapshots are captured only after a K8 scan completes. If the timeline is empty, run a scan from the Jobs page.
  • A high Recreated count for one workload is usually a crash-loop or redeploy rather than an attack. Cross-check the workload's events in your cluster before escalating.