Tagging strategy

Tags are the foundation of routing, dashboards, and roll-ups in DevFlow. We recommend five core tags, applied at the project level so every monitor inherits them.

the five core tags

• env — prod, staging, canary. Drives alert-routing and the quiet-hours rules in notification-throttling.
• service — payments-api, user-auth, etc. Used by SLO roll-ups.
• team — payments, platform, growth. The on-call rotation in on-call-schedules keys off this.
• owner — a person email. The "Was this monitor deliberately added?" conversation always starts here.
• slo — the SLO this monitor contributes data to. Empty if the monitor is not on the SLO path. See slo-overview.

applying tags

tags:
  env: prod
  service: payments-api
  team: payments
  owner: priya@example.com
  slo: payments-availability-99.9

Or, set defaults at the project level once:

devflow project set-tags payments-api   --tag env=prod   --tag service=payments-api   --tag team=payments   --tag slo=payments-availability-99.9

tag inheritance

• Workspace tags are inherited by every project.
• Project tags are inherited by every monitor in the project.
• Monitor-level tags override at the same key.

ad-hoc tags

Any string key:value works. We've seen teams add runbook, severity, feature_flag, change_id. As long as the five core are consistent, ad-hoc tags don't cause friction.

what NOT to tag

PII. Don't put customer ids or email addresses in tags. They're indexed and shown in lots of UI; treat them as printable.