Competing automations fighting over config (drift)

A setting keeps changing back. One automation sets an old default, a newer automation changes it, then a legacy script reverts it again — so two (or three) systems are fighting and the change won't stick.

How to pin it down:

1. Capture the flip. SSH in and read the running config repeatedly (SubnetSlinger has no scheduler — re-run it, or use Drift ▸ Golden config to compare each capture) and watch the value change. The Activity log time-stamps each check so you can see the cadence of the flips.

2. Correlate timing. The interval between flips usually matches one automation's run schedule — that points at the culprit.

3. Find ALL the actors. The modern trap: some tooling has been migrated to MCP/agentic access while legacy scripts still run. Both are live. You have to track down each one and reconcile them to a single source of truth — that's the real fix, not just re-setting the value.

Today this is a known industry problem — drift comes from competing configs and an unclear source of truth. The durable fix is one authoritative source of truth with drift detection, not more one-off changes.