Email Service Minute Quota High

Azure Communication Services (the cortiemailservices resource) allows 30 SendMail API requests per minute. This alert fires when a single minute reaches 24 — 80% of the quota.

The alert reads azure_acs_sendmail_apirequests_count from the acs-email-sendmail probe: the exact SendMail total per minute, aggregated across status codes by Azure itself (an Operation eq 'SendMail' filter returns a single timeseries — there are no per-status-code buckets to sum or mix). Each scrape publishes the newest non-null minute, so the series is a gauge — never apply rate() to it. The max_over_time(...[5m:1m]) subquery takes the worst single minute of the last five, and the rule fires with zero sustain (for: 0s): one hot minute is the signal, and the exact Azure-side count has no flukes to filter — the explicit zero overrides the runbook_alerts module's for: 5m default, which would otherwise delay the page by five minutes. Two lags stretch the effective lookback a little past the nominal five minutes: Azure data lands two to three minutes late, and a minute's bucket stays in the exporter's five-minute query window, so the hot minute being reported can be several minutes old.

Both dev-par01 and prd-par01 exporters probe the same shared Azure resource, so the expression deliberately carries no cluster or environment matchers; the outer max by (probe) collapses the two exporters' views into one series, so a burst pages once instead of once per exporter.

• Sibling alerts: 03-email-service-hourly-quota-high.md (the 100/hour quota), 04-email-service-send-throttled.md (critical, actual 429 throttling).
• Dashboard: Azure Communication Services Email Delivery — the send-volume panels show per-minute volume by status code (the dimensioned acs-email-api series, a different probe from this alert's).
• If the volume is legitimate and sustained, the quota is a Microsoft-side limit: request a raise through the Azure support plan, or batch and throttle the sender.