☁️ Azure Cost Management Scheduled Action Terraform Module

Emails a saved Cost Analysis view on a schedule — and expires, because end_date is required and there is no "never" (azurerm_cost_management_scheduled_action). Targets hashicorp/azurerm ~> 4.0.

• 📧 A recurring email of a saved Cost Analysis view — its chart, and optionally a CSV link.
• 🔴 Every schedule expires. end_date is required, there is no "never", and once it passes the emails stop with no warning and no plan diff. Azure caps it at one year.
• 🔴 Delivery depends on the creator's access. Azure checks that whoever created the schedule still holds Reader before sending each email. Lose it and the emails stop silently.
• ✅ Which makes Terraform an advantage: the identity running the apply becomes the creator, so applying from CI with a service principal keeps the schedule alive.
• 🔴 The view decides what the email contains. This resource owns the schedule and the recipients only — and view_id is force-new.
• 🔒 Recipients need no Azure access. Azure documents this explicitly, so email_addresses sends cost data outside Azure's access-control boundary.
• ⚠️ frequency carries documented conditional requirements, which this module enforces: Weekly needs days_of_week; Monthly needs either day_of_month or weeks_of_month with days_of_week.
• ⚠️ hour_of_day is UTC with no time-zone field, so a "morning report" is only morning for part of the year.
• ⚠️ The ARM namespace is shared with azurerm_cost_anomaly_alert — names must be unique across both.

💡 Why it matters: The two things most likely to break this are a date you set once and an access grant you never think about again. Neither produces an error, a diff, or a symptom other than an email that stops arriving.

If this module saves you time, please consider supporting its continued development:

• ⭐ Star the repository on GitHub.
• 🤝 Connect on LinkedIn: linkedin.com/in/microsoftexpert
• ☕ Buy me a coffee: buymeacoffee.com/microsoftexpert

flowchart TB
  creator["THE IDENTITY THAT RUNS THE APPLY becomes the schedule's CREATOR. Azure checks that it still holds Reader before sending each email, so if it loses that the reports STOP SILENTLY - record healthy, plan clean, nothing said. Apply from CI with a service principal."]
  view["terraform-azurerm-subscription-cost-management-view. IT decides which costs are reported and how they are grouped - this module only decides when and to whom. Force-new, and Azure cannot subscribe to management-group-scoped views or to table views."]
  sched["terraform-azurerm-cost-management-scheduled-action"]
  mailbox["A MONITORED SHARED MAILBOX. Azure documents that recipients need NO portal or Cost Management access to read the email, its chart or its CSV - so this list sends cost data outside Azure's access-control boundary."]
  alert["terraform-azurerm-cost-anomaly-alert: the same ARM type, so names must be unique across BOTH. It notifies on unexpected change; this one reports on a schedule."]
  exports["terraform-azurerm-subscription-cost-management-export and billing-account-cost-management-export: use an export when something must PROCESS the numbers, and this when a human must READ them."]
  expiry["AND EVERY SCHEDULE EXPIRES. end_date is REQUIRED with no never option, Azure caps it at one year, and once it passes the emails simply stop - no warning, no plan diff. It updates in place, so the fix is cheap; remembering is the hard part."]

  creator -->|"creates, and must keep Reader"| sched
  view -->|"view_id, force-new"| sched
  sched -->|"email_addresses, a disclosure boundary"| mailbox
  sched -->|"shares one namespace with"| alert
  exports -->|"the data-processing alternative"| sched
  sched -->|"but see"| expiry

  classDef mine fill:#0078D4,stroke:#004578,color:#fff;
  classDef keystone fill:#004578,stroke:#001f3f,color:#fff;
  classDef sib fill:#eef2f7,stroke:#b8c4d0,color:#1b1b1b;
  class sched mine;
  class creator,expiry keystone;
  class view,mailbox,alert,exports sib;

flowchart TB
  freq["frequency is Daily, Weekly or Monthly - and it carries DOCUMENTED conditional requirements, so they are ENFORCED: Weekly needs days_of_week, and Monthly needs either day_of_month OR weeks_of_month together with days_of_week."]
  placed["Both checks are PLACED ON frequency, one-directionally, because a validation may only reference its own variable and two variables checking each other is rejected as a cycle. So each message says which variable carries the check and why it names a field you were not editing."]
  ignored["ignored_schedule_fields: derived, because the provider documents these as applicable-when rather than forbidden-unless. It names anything supplied that CANNOT take effect - rejecting it would refuse a configuration Azure accepts. Assert empty."]
  dates["start_date and end_date, both REQUIRED, both RFC3339 UTC. end_date greater than start_date IS enforced. The one-year cap is NOT - the bound is a year from today or from start_date, whichever is LATER, so a check based on start_date alone would reject legal input."]
  utc["hour_of_day is UTC with NO time-zone field, so the local send time drifts with daylight saving. And day_of_month accepts 29 to 31, which do not occur in every month."]
  summary["schedule_summary: derived, because the schedule is spread across five interacting fields. A reviewer asking when does this actually send should not reassemble them mentally - and it always states UTC, because that is the mistake."]
  this["azurerm_cost_management_scheduled_action.this"]
  flags["stops_sending_after_end_date, delivery_depends_on_the_creators_access, recipients_need_no_azure_access, view_must_exist_and_is_not_created_here - four constants, because each one fails silently."]

  freq -->|"required"| this
  freq -->|"checks live here"| placed
  placed -->|"and the rest are reported"| ignored
  dates -->|"required, one check enforced and one documented"| this
  utc -->|"schedule detail"| this
  this -->|"reassembled into"| summary
  this -->|"emits"| flags

  classDef mine fill:#0078D4,stroke:#004578,color:#fff;
  classDef keystone fill:#004578,stroke:#001f3f,color:#fff;
  classDef sib fill:#eef2f7,stroke:#b8c4d0,color:#1b1b1b;
  class this mine;
  class freq mine;
  class flags,placed keystone;
  class ignored,dates,utc,summary sib;

Resource inventory

Schema notes that bite — confirmed against the live provider schema and its documentation:

• 🔴 end_date is required and delivery stops once it passes (example 2).
• 🔴 Delivery depends on the creating identity's continuing access (example 3).
• 🔴 view_id is force-new and decides the content — and management-group-scoped views and table views cannot be subscribed to (example 4).
• 🔴 The ARM type is shared with azurerm_cost_anomaly_alert (example 9).
• 🔒 Recipients need no Azure access (example 8).
• ⚠️ frequency carries documented conditional requirements (examples 5, 6).
• ⚠️ hour_of_day is UTC; there is no time-zone field (example 7).
• ⚠️ day_of_month accepts 29–31, which do not occur in every month (example 7).
• ⚠️ email_address_sender is the unsubscribe contact, not the From address (example 8).
• ⚠️ email_addresses is a list here and a set on the sibling; message allows 250 here and 100 there (example 9).
• ⚠️ No Annually frequency, unlike this library's cost-management export modules (example 5).
• ⚠️ Force-new: name, view_id (example 10).
• ⚠️ No tags attribute, so this module carries no tags variable.
• lifecycle is not valid inside a module block, so a caller cannot add prevent_destroy (example 11).

🔴 The fourth row is the one nobody audits. It is not a permission needed to apply, but one that must keep existing afterwards, held by the creating identity (example 3).

🔒 The last row is deliberate, not an omission (example 8).

• 🔴 A Cost Management view that supports subscribing — not a management-group-scoped view, and not a table view (example 4).
• 🔴 An identity that will retain Reader — ideally a service principal (example 3).
• 🔴 A plan for renewing end_date (example 2).
• ✅ A monitored shared mailbox for email_addresses and email_address_sender (example 8).
• ⚠️ For indirect Enterprise Agreements and Microsoft Customer Agreements, the view charges policy must be enabled, or the emails are suppressed regardless of this configuration (example 12).
• ⚠️ A name not already used by a cost anomaly alert in the same subscription (example 9).

terraform-azurerm-cost-management-scheduled-action/
├── providers.tf   # required_version + the pinned azurerm provider. No provider block.
├── variables.tf   # name, display_name, view_id, email_addresses, email_address_sender,
#                  # email_subject, message, frequency, start_date, end_date,
#                  # day_of_month, days_of_week, weeks_of_month, hour_of_day, timeouts
├── main.tf        # the keystone `this`
├── outputs.tf     # id first, then the view, recipients and schedule, then the derived and constant flags
├── README.md      # this document
├── SCOPE.md       # the cross-module contract
├── LICENSE        # MIT
└── .gitignore

provider "azurerm" {
  features {}
}

module "monthly_report" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-cost-management-scheduled-action.git?ref=v1.0.0"

  name         = "report-prod-monthly"
  display_name = "Production monthly cost report"

  # 🔴 The view decides the content, and this is force-new (example 4).
  view_id = var.cost_view_id

  # 🔒 A monitored shared mailbox: recipients need no Azure access (example 8).
  email_addresses      = ["cloud-cost-alerts@contoso.example"]
  email_address_sender = "cloud-cost-alerts@contoso.example"
  email_subject        = "Prod monthly cost report" # ≤ 70 characters

  frequency    = "Monthly"
  day_of_month = 1
  hour_of_day  = 8 # ⚠️ UTC, not local (example 7)

  start_date = "2026-08-01T00:00:00Z"
  end_date   = "2027-07-31T00:00:00Z" # 🔴 and then it stops (example 2)
}

🔴 Apply this from CI, not from your own session. The identity that applies becomes the creator, and the reports stop the day it loses access (example 3).

ℹ️ The caller configures the provider, its authentication, and the mandatory features {} block. This module declares none of them.

Consumes

ℹ️ No tags. The provider exposes none on this resource.

Emits

The examples below reference existing resources by ID or name rather than creating them; this module owns only its own resource. Those references are declared inputs:

variable "cost_view_id" {
  description = "id of an existing cost view that these examples reference but do not create."
  type        = string
}

variable "other_view_id" {
  description = "id of an existing other view that these examples reference but do not create."
  type        = string
}

module "daily_report" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-cost-management-scheduled-action.git?ref=v1.0.0"

  name                 = "report-prod-daily"
  display_name         = "Production daily cost report"
  view_id              = var.cost_view_id
  email_addresses      = ["cloud-cost-alerts@contoso.example"]
  email_address_sender = "cloud-cost-alerts@contoso.example"
  email_subject        = "Prod daily cost"
  frequency            = "Daily"
  start_date           = "2026-08-01T00:00:00Z"
  end_date             = "2027-07-31T00:00:00Z"
}

end_date = "2027-07-31T00:00:00Z"

1 Aug 2027   the emails stop
             -> the resource is healthy
             -> terraform plan is clean
             -> Azure sends no warning
             -> the first symptom is somebody asking where the report went

output "diarise_this" {
  value = module.monthly_report.stops_sending_after_end_date # always true
}

end_date = var.cost_report_end_date # bumped by CI on each run

Azure checks the CREATOR's permissions before sending each email:
  Reader — or Microsoft.CostManagement/scheduledActions/read — on the subscription
Lose it, and delivery ends. Record healthy. Plan clean. Nothing said.

output "who_created_this_matters" {
  value = module.monthly_report.delivery_depends_on_the_creators_access # always true
}

view_id = var.cost_view_id # ✅ a subscription-scoped Cost Management view

management-group-scoped views  ->  Subscribe is unavailable
table views                    ->  Subscribe is unavailable

output "check_the_view" {
  value = module.monthly_report.view_must_exist_and_is_not_created_here # always true
}

view_id must be a Cost Management view Resource ID ending in
/providers/Microsoft.CostManagement/views/<view>. ⚠️ Passing the scheduled action's own ID, or
a scope without the views segment, is the usual mistake.

frequency = "Daily"    # ✅ needs nothing else

frequency    = "Weekly"
days_of_week = ["Monday"] # 🔴 required

frequency    = "Monthly"
day_of_month = 1          # 🔴 either this…

frequency      = "Monthly"
weeks_of_month = ["First"]   # 🔴 …or this pair
days_of_week   = ["Monday"]

frequency = "Monthly" requires either day_of_month, or weeks_of_month together with
days_of_week — the provider documents this either/or, and weeks_of_month alone is not enough.

frequency must be exactly one of: Daily, Weekly, Monthly. The values are case-sensitive.
ℹ️ Note there is no Annually option here, unlike the cost-management *export* resources.

Both frequency checks are placed ON `frequency`, referencing the other variables
one-directionally — because a validation condition must reference its own variable, and two
variables validating each other is rejected as a cycle.

frequency = "Weekly" requires days_of_week to be set — the provider documents this. ⚠️ This
check is placed on `frequency` because a validation may only reference its own variable, so it
names days_of_week even when you were editing frequency.

output "dead_settings" {
  value = module.daily_report.ignored_schedule_fields # ⚠️ assert this is empty
}
# e.g. ["day_of_month"] when frequency = "Daily" and day_of_month = 1

hour_of_day = 8  # ⚠️ 08:00 UTC — NOT 08:00 local, and it does not follow daylight saving

day_of_month = 31 # ⚠️ does not occur in February, April, June, September or November
day_of_month = 28 # ✅ occurs in every month

day_of_month must be a whole number between 1 and 31. ⚠️ Remember 29, 30 and 31 do not occur in
every month, and Azure does not document what it does in a short month — prefer a day of 28 or
lower for a genuinely monthly report.

output "when" {
  value = module.monthly_report.schedule_summary # e.g. "Monthly day-1 at 08:00 UTC"
}

email_addresses      = ["cloud-cost-alerts@contoso.example"] # who receives the report
email_address_sender = "cloud-cost-alerts@contoso.example"   # ⚠️ the UNSUBSCRIBE contact

output "disclosure_boundary" {
  value = module.monthly_report.recipients_need_no_azure_access # always true
}

report-prod-monthly   -> this resource
anomaly-prod-daily    -> the sibling

# 🔴 Force-new:
name    = "report-prod-monthly-v2"
view_id = var.other_view_id

# ✅ Updates in place — including everything about the schedule:
display_name         = "Production monthly cost report (FinOps)"
email_addresses      = ["cloud-cost-alerts@contoso.example", "finops@contoso.example"]
email_address_sender = "cloud-cost-alerts@contoso.example"
email_subject        = "Prod monthly cost"
message              = "Owner: FinOps. Questions to #cloud-cost."
frequency            = "Weekly"
days_of_week         = ["Monday"]
start_date           = "2026-08-01T00:00:00Z"
end_date             = "2028-01-31T00:00:00Z" # ✅ extending is cheap
hour_of_day          = 7

output "scheduled_action_review" {
  value = {
    id       = module.monthly_report.id
    view     = module.monthly_report.view_id           # 🔴 go and look at it
    when     = module.monthly_report.schedule_summary  # ✅ one readable line
    dead     = module.monthly_report.ignored_schedule_fields # ✅ expect []
    expires  = module.monthly_report.end_date          # 🔴 diarise this
    who      = module.monthly_report.email_addresses   # 🔒 a mailbox, not people
    unsub    = module.monthly_report.email_address_sender
    # 🔴 Prompts, not values:
    expiry_warning  = module.monthly_report.stops_sending_after_end_date
    creator_warning = module.monthly_report.delivery_depends_on_the_creators_access
    disclosure      = module.monthly_report.recipients_need_no_azure_access
    view_warning    = module.monthly_report.view_must_exist_and_is_not_created_here
  }
}

terraform destroy on this module:
  removes the SCHEDULE     ->  and the reports stop
  the view survives — it was never owned here
  historical cost data is untouched

terraform import 'module.monthly_report.azurerm_cost_management_scheduled_action.this' \
  "/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.CostManagement/scheduledActions/report-prod-monthly"

provider "azurerm" {
  features {}
  # 🔴 Apply from CI as a service principal. That identity becomes the schedule's
  #    creator, and its continuing Reader access keeps the reports arriving (example 3).
}

# ── The creating identity's own access, kept where it is visible ─────────────
module "cost_reader" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-role-assignments.git?ref=v1.0.0"

  scope = "/subscriptions/00000000-0000-0000-0000-000000000000"
  role_assignments = {
    pipeline_reader = {
      role_definition_name = "Reader"
      principal_id         = var.pipeline_principal_object_id
    }
  }
}

# ── The view: what the report actually contains (example 4) ──────────────────
# ℹ️ Built by terraform-azurerm-subscription-cost-management-view, whose own
#    required inputs (timeframe, chart type and dataset among them) are covered in
#    that module's documentation and are omitted here rather than half-stated.
# ⚠️ Whatever you build there must be neither a table view nor management-group
#    scoped — neither can be subscribed to.
#   module "cost_view" {
#     source = ".../terraform-azurerm-subscription-cost-management-view..."
#     name   = "prod-monthly-by-service"
#     ...
#   }

# ── This module: the schedule and the recipients ─────────────────────────────
module "monthly_report" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-cost-management-scheduled-action.git?ref=v1.0.0"

  # ⚠️ Prefixed by kind: the namespace is shared with anomaly alerts (example 9).
  name         = "report-prod-monthly"
  display_name = "Production monthly cost report"

  # 🔴 Force-new, passed as an attribute so the view outlives the schedule (example 4).
  view_id = var.cost_view_id

  # 🔒 One monitored shared mailbox. Recipients need no Azure access (example 8).
  email_addresses      = ["cloud-cost-alerts@contoso.example"]
  email_address_sender = "cloud-cost-alerts@contoso.example" # ⚠️ unsubscribe, not From

  email_subject = "Prod monthly cost report"                 # ≤ 70 (example 9)
  message       = "Owner: FinOps. Questions to #cloud-cost." # ≤ 250 here (example 9)

  # ✅ Monthly via day_of_month, which satisfies the documented either/or (example 5).
  frequency    = "Monthly"
  day_of_month = 1  # ✅ 1 rather than 31: every month has it (example 7)
  hour_of_day  = 8  # ⚠️ UTC (example 7)

  start_date = "2026-08-01T00:00:00Z"
  # 🔴 Driven by a variable the pipeline refreshes, so expiry is renewed rather than
  #    remembered (example 2).
  end_date = var.cost_report_end_date
}

# ── The anomaly counterpart: surprises rather than routine ───────────────────
module "anomaly_alert" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-cost-anomaly-alert.git?ref=v1.0.0"

  name            = "anomaly-prod-daily" # ⚠️ different prefix (example 9)
  display_name    = "Production daily cost anomaly"
  email_addresses = ["cloud-cost-alerts@contoso.example"]
  email_subject   = "Prod cost anomaly detected"
}

output "cost_reporting_posture" {
  value = {
    schedule = module.monthly_report.schedule_summary       # ✅ one readable line
    dead     = module.monthly_report.ignored_schedule_fields # ✅ expect []
    expires  = module.monthly_report.end_date               # 🔴 diarise
    view     = module.monthly_report.view_id
    # 🔴 Runbook facts, not statuses:
    expiry_warning  = module.monthly_report.stops_sending_after_end_date
    creator_warning = module.monthly_report.delivery_depends_on_the_creators_access
  }
}

ℹ️ There is no tags variable, because the provider exposes no tags attribute on this resource.

variable "frequency" {
  type = string
  # Required. The provider DOCUMENTS conditional requirements, so they are enforced — and both checks are placed here,
  # one-directionally, because a validation may only reference its own variable. See examples 5 and 6.
  validation {
    condition     = contains(["Daily", "Weekly", "Monthly"], var.frequency)
    error_message = "frequency must be exactly one of: Daily, Weekly, Monthly … ℹ️ Note there is no Annually option here, unlike the cost-management *export* resources …"
  }
  validation {
    condition     = var.frequency == "Weekly" ? length(coalesce(var.days_of_week, [])) > 0 : true
    error_message = "frequency = \"Weekly\" requires days_of_week to be set … ⚠️ This check is placed on `frequency` because a validation may only reference its own variable …"
  }
  validation {
    condition     = var.frequency == "Monthly" ? (var.day_of_month != null || (length(coalesce(var.weeks_of_month, [])) > 0 && length(coalesce(var.days_of_week, [])) > 0)) : true
    error_message = "frequency = \"Monthly\" requires either day_of_month, or weeks_of_month together with days_of_week … weeks_of_month alone is not enough …"
  }
}

variable "end_date" {
  type = string
  # 🔴 REQUIRED — there is no "never expires", and delivery stops silently once it passes. `end_date > start_date` is
  # enforced; Azure's one-year cap is NOT, because the bound is a year from today or start_date whichever is LATER, so a
  # check based on start_date alone would reject legal input. See example 2.
  validation {
    condition     = can(formatdate("YYYY-MM-DD", var.end_date)) && can(formatdate("YYYY-MM-DD", var.start_date)) ? timecmp(var.end_date, var.start_date) > 0 : true
    error_message = "end_date must be later than start_date. ⚠️ Placed on end_date one-directionally … ℹ️ Azure additionally caps the end date at one year out; that bound depends on when the apply runs, so it is documented rather than enforced."
  }
}

ℹ️ Nothing here is secret. Email addresses are personal data, not credentials (example 8).

• This resource has two independent silent failure modes, and the module is organised around them. A schedule can stop because its end_date passed, or because the identity that created it lost access — and neither produces an error, a plan diff, or any symptom beyond an email that no longer arrives. Both are constant outputs for that reason.

• The expiry is the more certain of the two, because it is guaranteed. end_date is required, Azure caps it at a year, and every schedule therefore has a date on which it stops working. The module names the cheap remedy — the field updates in place — and recommends driving it from a pipeline-refreshed value so renewal is automatic rather than remembered.

• The one-year cap is documented and deliberately not enforced, and the reasoning is worth stating because it looks like an omission: the bound is one year from today or start_date, whichever is later, so with a past start_date the real limit exceeds anything a start_date-based check could allow. Enforcing it would reject legal input. end_date > start_date is enforced, since that can never be legal.

• The creator-access dependency is improved by using Terraform, which is worth saying out loud. Because the applying identity becomes the creator, applying from CI does what Microsoft recommends without anybody needing to know why — provided the module says so, which it does in the overview, the permissions table, the runbook and an output. The corollary matters too: a force-new change re-parents the creator to whoever applied it.

• The documented conditional requirements are enforced; the applicability notes are not. Weekly requiring days_of_week and Monthly requiring day_of_month or the weeks_of_month pair are published requirements, so they are validation {} blocks. day_of_month being applicable when monthly is not a prohibition — Azure accepts and ignores it — so ignored_schedule_fields reports it instead. Rejecting it would refuse a working configuration.

• Both conditional checks are placed on frequency, one-directionally, because a validation {} condition must reference its own variable and two variables validating each other is rejected as a cycle. Each message says which variable carries the check, so naming a field the caller was not editing does not read as a bug.

• schedule_summary exists because five fields interact. frequency, weeks_of_month, days_of_week, day_of_month and hour_of_day combine differently depending on the first of them, and a reviewer asking "when does this send?" should get an answer rather than a reassembly task. It always states UTC, because that is the mistake.

• view_id is the field that decides whether the module is useful at all, and it is force-new. The two unsupported view kinds — management-group scope and table views — are invisible from a Resource ID, so they are documented as a prerequisite and carried in a constant output.

• recipients_need_no_azure_access is a privacy statement. Azure documents that recipients need no portal or Cost Management access, so cost data leaves the access-control boundary the moment an address is added. Following this library's rule on privacy-not-secrecy, the module surfaces that and refers retention and lawful basis to whoever owns data protection.

• No character rule is invented for name. The sibling anomaly-alert resource documents lowercase-only; this one documents nothing, so only non-emptiness and a not-a-Resource-ID check apply. That asymmetry, the list/set difference, the inverted message caps and the required-versus-optional unsubscribe contact are all tabulated rather than smoothed over, because a reader will otherwise assume the family is symmetric.

• Duplicates in days_of_week and weeks_of_month are rejected. The provider takes lists rather than sets, so a repeated value type-checks and means nothing to Azure — the kind of no-signal mistake worth catching at plan time.

• Before applying: apply from CI, so the creator is a service principal.
• Before merging: diarise end_date, or drive it from CI.
• Before trusting the report: go and look at the view.
• Before adding a recipient: they will read your cost data with no Azure role.
• Before setting hour_of_day: it is UTC, and it will not follow daylight saving.

terraform init -backend=false
terraform validate
terraform fmt -check

• Pin the source to a tag — ?ref=v1.0.0 — never a branch.
• Plan-only from here. A human applies from CI.
• 🔴 Extend end_date before it passes, or the reports stop (example 2).
• 🔴 Apply from CI, and keep that identity's Reader in place (example 3).
• 🔴 Force-new: name, view_id — and a replacement re-parents the creator (example 10).
• ✅ In place: every schedule field, the recipients, and end_date.
• ⚠️ Assert ignored_schedule_fields is empty (example 6).
• ⚠️ Read schedule_summary rather than reassembling five fields (example 7).
• ⚠️ Prefix names by kind — the namespace is shared (example 9).
• ⚠️ Allow-list microsoft-noreply@microsoft.com (example 8).
• 💡 A CanNotDelete lock matters more than usual: a deleted schedule has no symptom (example 11).

terraform validate and terraform fmt -check are the offline gate. They confirm:

• name is non-empty and is not a Resource ID;
• view_id ends in /providers/Microsoft.CostManagement/views/<view>;
• email_addresses has at least one entry and every entry looks like an email address;
• email_address_sender looks like an email address;
• email_subject is non-empty and at most 70 characters, and message at most 250;
• frequency is exactly Daily, Weekly or Monthly;
• Weekly has days_of_week, and Monthly has day_of_month or the weeks_of_month + days_of_week pair;
• start_date and end_date are RFC3339, and end_date is later than start_date;
• day_of_month is a whole number 1–31, and hour_of_day a whole number 0–23;
• days_of_week and weeks_of_month contain only legal, non-duplicated values;
• the module declares no provider block and no tags variable.

💡 These were proved by evaluating the conditions in terraform console inside the module — which does fire root-module variable validations, unlike terraform validate on a calling configuration. "Weekly" with no days_of_week fires the weekly conditional, "Monthly" with only weeks_of_month fires the monthly either/or, an end_date before start_date fires the ordering check, "monday" fires the case check, a duplicated day fires the distinct check, and 32 fires the day-of-month range.

⚠️ And note a property of the harness: Terraform skips a validation whose referenced variable has already failed — which matters more here than usual, because the frequency checks reference four other variables. A short error list is not proof a check is missing.

🔴 What the gate deliberately does not attempt: Azure's one-year end_date cap (it depends on when the apply runs), the applicability of day_of_month on a non-monthly schedule (reported instead), or whether the view supports subscribing.

What only plan and apply exercise:

• whether the view exists and is readable;
• whether the caller may create scheduled actions;
• whether the name is already taken by an anomaly alert (example 9).

What no Terraform command checks at any stage:

• 🔴 whether the creating identity will keep its access (example 3);
• 🔴 whether anybody will notice when end_date passes (example 2);
• 🔴 whether the view is a table view or management-group scoped (example 4);
• ⚠️ whether the billing-side view charges policy suppresses the emails (example 12);
• whether the recipients should be receiving cost data at all (example 8).

Outputs:

day_of_month                            = 1
delivery_depends_on_the_creators_access = true
display_name                            = "Production monthly cost report"
days_of_week                            = null
email_address_sender                    = "cloud-cost-alerts@contoso.example"
email_addresses                         = ["cloud-cost-alerts@contoso.example"]
email_recipient_count                   = 1
email_subject                           = "Prod monthly cost report"
end_date                                = "2027-07-31T00:00:00Z"
frequency                               = "Monthly"
hour_of_day                             = 8
id                                      = "/subscriptions/00000000-.../providers/Microsoft.CostManagement/scheduledActions/report-prod-monthly"
ignored_schedule_fields                 = []
message                                 = "Owner: FinOps. Questions to #cloud-cost."
name                                    = "report-prod-monthly"
recipients_need_no_azure_access         = true
schedule_summary                        = "Monthly day-1 at 08:00 UTC"
start_date                              = "2026-08-01T00:00:00Z"
stops_sending_after_end_date            = true
view_id                                 = "/subscriptions/00000000-.../providers/Microsoft.CostManagement/views/prod-monthly-by-service"
view_must_exist_and_is_not_created_here = true
weeks_of_month                          = null

✅ schedule_summary = "Monthly day-1 at 08:00 UTC" is the line to show whoever asked for the report — and note it says UTC (example 7).

✅ ignored_schedule_fields = [] proves the schedule written is the schedule that runs (example 6).

🔴 end_date = "2027-07-31T00:00:00Z" is the date to diarise. Nothing will remind you (example 2).

ℹ️ days_of_week and weeks_of_month are null because this monthly schedule uses day_of_month — the other valid route (example 5).

🔴 The four true constants are facts, not statuses. None means "checked and fine".

• azurerm_cost_management_scheduled_action — provider documentation, including the conditional requirements of example 5 and the length caps of example 9.
• Save and share customized views — the creator-access behaviour of example 3, the one-year end_date cap and silent expiry of example 2, the unsupported view kinds of example 4, and the view charges policy of example 12.
• What is Microsoft Cost Management — how scheduled alerts sit alongside budgets, anomalies and exports, and the note that recipients need no portal access (example 8).
• Cost Management scheduled action modules — Microsoft's own framing of the schedule/anomaly pair.
• Sibling modules: terraform-azurerm-cost-anomaly-alert (unexpected change rather than a schedule — the same ARM namespace, example 9), terraform-azurerm-subscription-cost-management-view (the view of example 4), terraform-azurerm-subscription-cost-management-export and terraform-azurerm-billing-account-cost-management-export (data rather than a chart), terraform-azurerm-role-assignments (the creating identity's Reader, example 12).
• This module's SCOPE.md.

💙 "Infrastructure as Code should be standardized, consistent, and secure."