Under GitOps this hurts twice. Argo CD happily syncs the new Secret, reports Synced, and moves on — the workload stays stale while the dashboard is green. So somebody runs kubectl rollout restart, by hand or from a pipeline. That restart is an undeclared change, and it ignores the freeze windows on your AppProject, because sync windows only ever constrained Argo CD's own syncs.

KICK closes the gap from inside the GitOps model. It detects the change, confirms the running rollout is older than it, and reads spec.syncWindows straight off the owning AppProject — no sidecar, no plugin, no window definitions copied into a second place. A restart KICK triggers is subject to the same freeze as a sync. All it writes is the standard kubectl.kubernetes.io/restartedAt annotation: no hashes, no environment variables, no KICK-owned fields on your workloads.

    flowchart LR
  A[Secret / ConfigMap<br/>changes] --> B[Observe<br/>fingerprint]
  B --> C[KickRequest<br/>per workload]
  C --> D{Schedule<br/>window}
  D -->|closed| W[Wait]
  D -->|open| G{GitOps gate<br/>if enabled}
  G -->|blocked| W
  G -->|allowed| E{Rollout<br/>stale?}
  E -->|no| S[Skip]
  E -->|yes| R[Restart<br/>restartedAt]
  

When the restart happens

Inside your Argo CD sync windows

Read from the owning AppProject. A closed window blocks the restart with OutsideSchedule and re-checks when it opens.

Once Argo CD is settled

Waits for the owning Application to finish its operation and report Synced.

When Flux is done

Waits for the owning Kustomization or HelmRelease to be Ready and not reconciling.

Inside a window you define

Cron Allow / Deny windows in the time zone you specify, for clusters with no GitOps tool.

Right away

The default. No GitOps tool, no schedule, no configuration.

I want to...

Using an AI agent?

Point it at one URL instead of crawling the site.