A hundred eyes across every cluster — detecting, diagnosing and repairing before your pager does.
Sign in to manage your fleet.
Liveupdated just now
Ordered by most recent finding, not by state change — this system has no state-transition history to order by (`timeline_events` is unwritten), and a resolved-vs-opened split needs a close timestamp the schema does not record either.
6 clustersLiveUpdated just now
| Node | Status | CPU usage | Memory usage |
|---|---|---|---|
| prod-eu-1-control-0 | Ready | 407 millicores20% of 2 cores | 6.9 GiB42% of 16.4 GiB |
| prod-eu-1-worker-0 | Ready | 63 millicores2% of 4 cores | 2.1 GiB6% of 32.9 GiB |
| prod-eu-1-worker-1 | Ready | 87 millicores2% of 4 cores | 2.1 GiB6% of 32.9 GiB |
What this agent may change
Answered by this cluster’s own API server, not read from the chart value that was meant to grant it — so it stays true if the two have drifted. This is the cluster-wide (all-namespaces) answer.
178 incidentsLiveUpdated just now
container "api" is waiting: CrashLoopBackOff (back-off 5m0s restarting failed container=api pod=api-5c7f4f4b45-xq8jl_gateway(247a5763-fdef-4afc-9839-6c0f5e020757))
v1/Pod gateway/api-5c7f4f4b45-xq8jl: container "api" is waiting: CrashLoopBackOff (back-off 5m0s restarting failed container=api pod=api-5c7f4f4b45-xq8jl_gateway(247a5763-fdef-4afc-9839-6c0f5e020757))
ARGUS check Read by ARGUS from the Pod’s own status, which does not depend on the cluster having emitted a matching Warning event. This incident also carries findings from the other kind of detection — open “What happened” below to see which reason came from which.
Managed by Argo CD Argo CD Application storefront-api
Container init is OOM-killed because the memory limit (32Mi) is insufficient for the workload's allocation requirement. The deployment's command writes 48MB to /dev/shm (`dd bs=1M count=48`), whose pages are charged against the container's memory cgroup, but the spec sets `resources.limits.memory: 32Mi` in apps/api/deployment.yaml:38. The manifest's own comment (line 37) confirms this is the fault condition and states "the fix raises it back" to 128Mi. This deployment is managed by Argo CD (Application storefront-api in namespace argocd, sourced from https://github.com/acme-platform/manifests.git at f27a97a1f0d7c74ab6b31ab45c1847f2e5ba5b34, path apps/api), so a live kubectl patch would be reverted by the next reconcile — the durable fix is raising the memory limit to at least 64Mi (to accommodate the 48MB allocation plus runtime overhead) in the source repository.
100% confidence (high)
The pod is experiencing OOM kills due to insufficient memory limits
Finding: Pod is OOM-killed during container init because its command allocates 48MB to /dev/shm but memory limit is only 32Mi; owned by Deployment api in gateway
This is a GitOps-managed deployment requiring source repository fix
Finding: Deployment is managed by Argo CD Application storefront-api, sourced from github.com/acme-platform/manifests.git at commit f27a97a1f0d7c74ab6b31ab45c1847f2e5ba5b34, path apps/api
Need to read the manifest to propose correct memory limit
Finding: Manifest apps/api/deployment.yaml sets memory limit to 32Mi on line 38; comment on line 37 confirms this induces OOMKill and states fix raises it back to 128Mi; 64Mi is sufficient for 48MB allocation plus overhead
Evidence gathered: 7 tool calls — 2 × describe resource, 1 × GitOps ownership, 1 × list repo files, 1 × owner chain, 1 × pod logs, 1 × read repo file
claude-sonnet-4-5-20250929 · 19 iterations · 23,159 tokens · $0.1347 · 4d ago
ARGUS proposes this as a change to the repository the object came from, not as an in-place patch — use "Propose this fix as a pull request" above, which computes the diff against the file(s) as they are today for you to review before anything is opened. It does not verify that only the intended thing changed.
Pull request: a GitOps controller applies this object's manifest with automated sync enabled — an in-place patch has a few-second half-life under selfHeal, since the controller reconciles it straight back; the durable fix is a pull request
See the 3 tool calls this is built from ↑
Recommended remediation
risk "low" is within this policy's ceiling "low", reversible=true, and confidence 1.00 meets the 0.90 threshold
How this fix reaches the cluster
A pull request your team reviews. The durable fix — prepare it below.
Make the same change in the manifest this app syncs from, and let Argo CD apply it.
https://github.com/acme-platform/manifests.gitapps/apif27a97a1f0d7 Proposed change — apps/api/deployment.yaml
resources: |
limits: |
memory: 32Mi |
memory: 64Mi |
requests: |
memory: 32Mi |
memory: 64Mi |
The PVC is pending because no PV matches its requirements or the StorageClass cannot provision one — The PVC has no StorageClass set and the FailedBinding event 'no persistent volumes available for this claim and no storage class is set' has repeated 296,821 times over 51+ days describe_resource: unchecked get_events: unchecked
The PVC was created by a StatefulSet; checking ownership to see if this is an orphaned claim or if the StatefulSet still references it — The PVC has no ownerReferences. StatefulSet prometheus-metrics-store-prometheus exists at 1/1 ready with pod prometheus-metrics-store-prometheus-0 running, suggesting the PVC name matches the StatefulSet's naming pattern get_owner_chain: unchecked list_resources: unchecked
The running pod is using a different volume or no volume at all, and this PVC is orphaned — The pod mounts an emptyDir volume at /prometheus, not the pending PVC. The StatefulSet spec also declares prometheus-metrics-store-prometheus-db as an emptyDir, not a volumeClaimTemplate. The StatefulSet is Helm-managed by release metrics-store describe_resource: unchecked
The PVC was created by an earlier StatefulSet version that had a volumeClaimTemplate, later changed to emptyDir, leaving this claim orphaned — The PVC is not GitOps-managed and is the only PVC in the namespace. The PVC was created at 11:21:14, 16 minutes before the StatefulSet at 11:37:38, confirming it predates the current StatefulSet configuration get_gitops_ownership: unchecked list_resources: unchecked
Considered and ruled out:
The PVC is waiting for a StorageClass to provision a volume — spec.storageClassName is not set, so no dynamic provisioner will act on this claim
A Pod is blocked waiting for this PVC to bind — The only pod with a matching ordinal (prometheus-metrics-store-prometheus-0) is Running 3/3 and mounts an emptyDir at /prometheus, not this PVC
Needs your approval: blocked from auto-approval by a hard safety floor: risk=high and reversible=false
high-risk, irreversible actions are never auto-approved regardless of confidence or policy. The plan declared "low"; the deterministic floor for a DeleteResource targeting v1/PersistentVolumeClaim in namespace "observability" is "high", and a declared level is never allowed to sit below it
Approving patches the live object in this cluster now; nothing is written to Git.
If you decline: the incident is dismissed — if the underlying fault is still there, its detector opens a new incident, since dismissing this plan doesn't mute detection. If you leave it pending: nothing executes on its own — ARGUS re-notifies at 48 hours, then 5 days, then 12 days, then weekly after that, for as long as it waits here; it never auto-approves and never expires.
Delete observability/prometheus-metrics-store-prometheus-db-prometheus-metrics-store-prometheus-0
Permanently deletes this object from the cluster. This cannot be undone by ARGUS — recovery, if any, depends entirely on whatever recreates it afterwards.
Approved by sre@example.com · 4d ago
Pull request merged
Pull request
Resolved — no new findings during the re-check window
8 changes in the last 7 days
Every change ARGUS has made to a cluster: a remediation applied in place, and a repository change whose pull request merged. Pull requests still waiting to be merged are listed too, marked Open — not merged: those have changed nothing yet, and merging one is what applies it. Undoing a change reverses what ARGUS did; it does not fix the problem that prompted it.
| What | How | Outcome | Cluster | Applied by | When | Undo |
|---|---|---|---|---|---|---|
payments/fraud-scoringDeploymentScale payments/fraud-scoring to 6 replicas | In place | Failed gateway: cluster is not connected | prod-eu-1 | sre@example.com | 25m ago | This execution did not succeed, so there is nothing to undo execution exec_01m37aa1s2dnd4fgerzqsexexk has outcome "failed". A failed execution may have applied part of its change, none of it, or all of it before failing to record — so "put it back to what it was" is not a statement anyone can make truthfully here. Re-analyse the incident so a fresh plan is derived from the cluster's actual current state. |
platform/auth-serviceDeploymentRestart platform/auth-service | In place | Applied | prod-eu-1 | sre@example.com | 32m ago | This action has no undo No compensating action was recorded for this execution. That is expected for a workload restart — the pods it replaced are already gone, so there is nothing to restore — and it is why the undo control does not appear for one. For any other action type it means the execution predates rollback capture. |
50 events on this page · more availableLatest first
| Event | Actor | Outcome | When | Details |
|---|---|---|---|---|
Login Succeeded— | sre@example.com | success | 9/23/2026, 2:42:37 PM | |
Login Succeeded— | sre@example.com | success | 9/23/2026, 2:41:55 PM | |
Login Succeeded— | sre@example.com | success | 9/23/2026, 2:29:32 PM | |
Login Succeeded— | sre@example.com | success | 9/23/2026, 2:27:27 PM | |
Login Succeeded— | sre@example.com | success | 9/23/2026, 2:26:49 PM | |
Login Succeeded— | sre@example.com | success | 9/23/2026, 2:24:31 PM | |
Login Succeeded— | sre@example.com | success | 9/23/2026, 2:23:01 PM | |
Login Succeeded— | sre@example.com | success | 9/23/2026, 2:22:14 PM | |
Generate Demo Dataprod-eu-1 | sre@example.com | success | 9/23/2026, 2:21:56 PM |