> ## Documentation Index > Fetch the complete documentation index at: https://docs.devhelm.io/llms.txt > Use this file to discover all available pages before exploring further. # Learn: Monitoring as Code > Why managing monitoring configuration as code improves reliability and team velocity Monitoring as Code (MaC) treats your monitoring setup like application code — versioned, reviewed, tested, and deployed through CI/CD. Instead of clicking through dashboards, you define monitors, alerts, and policies in configuration files. ## The problem with dashboard-only monitoring When monitoring configuration lives only in a web UI: * **No version history** — who changed that alert threshold last week? * **No review process** — changes go live without team review * **No reproducibility** — setting up a new environment means manual recreation * **Configuration drift** — staging and production diverge silently * **Bus factor** — only the person who clicked the buttons knows the setup ## How Monitoring as Code works MaC follows the same principles as Infrastructure as Code (IaC): 1. **Define** monitors, channels, and policies in a declarative format (YAML, HCL, or code) 2. **Version** the config in Git alongside your application code 3. **Review** changes through pull requests with team review 4. **Test** by validating syntax and previewing changes before applying 5. **Deploy** automatically through CI/CD on merge to main ## Benefits ### Reproducibility Spin up identical monitoring for a new environment in seconds: ```bash theme={null} devhelm deploy -f devhelm.yml --yes ``` Every team member gets the same monitoring setup — no manual steps, no missed configurations. ### Auditability Git provides a complete history of every change: ``` commit a1b2c3d — feat: add SSL certificate monitoring commit d4e5f6a — fix: reduce API health check frequency to 30s commit g7h8i9j — chore: add PagerDuty escalation for production ``` ### Review process Monitoring changes go through the same PR review as code changes. Team members can catch issues like: * Missing alerts on critical services * Overly aggressive check frequencies * Incorrect assertion thresholds ### Drift prevention When someone changes a monitor through the dashboard, the next deploy reverts it to what's in code. The YAML file is always the source of truth. ### Disaster recovery If you need to rebuild your monitoring from scratch, the config file has everything. No screenshots of dashboard settings, no tribal knowledge. ## Declarative vs imperative | Approach | Tools | How it works | | --------------- | -------------------------- | ----------------------------------------------------------------------------- | | **Declarative** | YAML config, Terraform HCL | Describe the desired state; the tool figures out what to create/update/delete | | **Imperative** | SDK scripts, CLI commands | Write step-by-step instructions to create each resource | Declarative is preferred for monitoring configuration because it handles drift, deletion, and idempotency automatically. ## Getting started DevHelm supports MaC through multiple tools: Define everything in devhelm.yml — fastest path. Manage monitors alongside cloud infrastructure. Automate deploys on every push. Move from dashboard-only to code-managed monitoring.