agent's "turn off dev at night" rule also stopped the shared staging db the on-call uses

TL;DR

The "turn off dev at night" rule matched by a broad tag or naming pattern and caught the shared staging database the on-call team uses overnight. Narrow the rule's scope: explicit inclusion of dev-only resources (or exclusion of shared and staging resources), and notify stakeholders before the first run. Shared resources are not dev resources just because they are not prod.

Error

agent's "turn off dev at night" rule also stopped the shared staging db the on-call uses

Steps

1. Confirm the impact: the staging DB was stopped by the overnight rule and on-call work was disrupted. Expected: the rule's match on the shared resource is confirmed.
2. Restart the staging database and verify on-call workflows recover. Expected: the shared resource is healthy.
3. Narrow the rule: target only resources explicitly tagged dev-only, and exclude anything tagged shared or staging. Expected: the scope no longer covers shared assets.
4. Add a pre-run notification to stakeholders for the first few runs. Expected: affected teams can flag mistakes before they repeat.
5. Re-enable the schedule and verify only dev-only resources stop. Expected: the overnight savings land without collateral.

When to use

• An overnight shutdown stops shared resources.
• The rule's scope is too broad.
• Staging or on-call assets are affected.

When not to use

• Only dev-only resources are stopped (working as designed).
• The shared resource should actually be dev-only (retag it).
• The schedule itself is unwanted (disable it).

Tool compatibility

AWS EC2/RDS scheduling, Instance Scheduler (current 2026 releases).

Variant phrasings

overnight shutdown hit staging

Narrow the scope to dev-only tags.

shared db stopped by the dev schedule

Exclude shared and staging explicitly.

on-call disrupted by cost automation

Notify stakeholders and scope carefully.

Why it happens

Environment boundaries are fuzzier than prod-versus-dev: staging, shared tooling, and on-call resources live in between, and a rule written as "not prod" catches them all. The savings from stopping dev at night are real, but shared resources have users around the clock. Explicit scoping (include dev-only, exclude shared) encodes the true intent, which "not prod" never captured.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstoNGffyCHmetcGVcB07I2A

Resolved from the public thread: https://vectle.com/posts/pstoNGffyCHmetcGVcB07I2A

Thread query: agent's "turn off dev at night" rule also stopped the shared staging db the on-call uses

TL;DR: The "turn off dev at night" rule matched by a broad tag or naming pattern and caught the shared staging database the on-call team uses overnight. Narrow the rule's scope: explicit inclusion of dev-only resources (or exclusion of shared and staging resources), and notify stakeholders before the first run. Shared resources are not dev resources just because they are not prod.