Skip to main content
Two distinct things live under an environment’s settings that people sometimes conflate: deploy identity (a read-only fact sheet showing what deploy unit sureops targets) and recovery cooldown (how long sureops waits for a stable recovery before auto-closing an incident). Neither is something you fill out — both are discovered or tuned, not authored from scratch.

​
Deploy identity

Deploy identity is a read-only section that shows the deploy coordinates sureops has discovered for an environment — which Argo CD Application it maps to, what namespace and project it lives in, its source repo and revision, and its sync policy. It lives in Settings → Environment → Operating Context, under Discovered deploy identity. This is not something you configure. sureops populates it one of two ways:
  • Discovered at provision — seeded when your environment is set up
  • Observed from Argo CD — inferred from live GitOps state
It grounds remediation (rollback recommendations, source-revert PRs) on real coordinates instead of guessing which deployable unit an incident actually belongs to.

​
What it shows

Below the coordinates, a Sync policy row shows three read-only facts: Auto-sync, Self-heal, and Prune — whichever of these your Argo CD Application has turned on. If self-heal is on, the panel notes an important asymmetry:
With self-heal on, a runtime rollback (e.g. rolling back a Deployment directly) is reverted on Argo CD’s next reconcile — it’s ephemeral, not durable. A source-revert PR — reverting the change in the source repo Argo CD tracks — is the durable fix. An auto-synced app will also refuse a manual sync to an older revision, so a runtime rollback may not even be executable regardless of self-heal.

​
If this looks wrong

Discovered facts aren’t edited inline. If the deploy identity sureops discovered doesn’t match reality, correct it by authoring an override in Environment → Landscape — committing a .sureops contract entry. A customer-authored override is locked from being overwritten by discovery and takes precedence over it. If no deploy node has been discovered for an environment yet, this section simply doesn’t appear — that’s expected for environments sureops hasn’t connected to a GitOps source.

​
Recovery cooldown

Recovery cooldown isn’t a retry throttle — sureops doesn’t loop retrying a failed fix. It’s a stability window that has to hold before an incident is allowed to auto-close, so a brief, misleading recovery blip doesn’t get mistaken for a real fix. It’s tuned per severity (P1 most cautious, P5 least) and configured from a Recovery Cooldown panel inside Settings → Environments → [environment] → Details — it isn’t a separate nav destination, just a panel further down the same Details page. Four knobs, all in minutes, all per severity (P1–P5): Defaults for Stability Dwell, Re-fire Window, and Recovery Watch Window are severity-scaled — P1 waits longest, P5 shortest. For example, the effective time before a P1 incident can auto-close is the larger of its dwell and re-fire window (30 minutes by default); for P3 it’s 15 minutes. Recurrence Lookback is the exception: it defaults to a flat 24 hours for every severity, P1 through P5. A 60-second background sweep continuously re-checks open incidents against these windows — there’s no separate “retry” timer to configure. Each knob accepts 1–1440 minutes (Recurrence Lookback also accepts 0, to disable recurrence detection for that severity). Leaving a field blank means the environment inherits the organization default for that severity; there’s a Reset to org default action to clear an environment-level override entirely.
A flapping incident (one that keeps re-triggering) is never auto-closed regardless of these settings — flapping always routes to human review.
  • Roles & Capabilities — Admin role required to edit recovery cooldown or author a landscape override
  • Notifications — configure who gets notified as incidents progress