Email Service Hourly Quota High

Azure Communication Services allows 100 SendMail API requests per hour. This alert fires when the trailing-hour total is at or above 80 — 80% of the quota — for five minutes.

The alert reads azure_acs_sendmail_hourly_apirequests_count from the acs-email-sendmail-hourly probe: the exporter asks Azure for a single PT1H bucket over the timespan [now-1h, now], and Azure computes the total server-side on every scrape. The number is exact and the window is rolling — no PromQL window math on top.

Why not rebuild the hour from the per-minute series? Because the exporter exposes a timestamp-less gauge (each scrape publishes only the newest non-null bucket), so sum_over_time over scrape samples counts a bucket once per scrape it survives: on 2026-10-30 the rebuilt "trailing hour" read 90-95 while Azure's own totals for the same windows were 38-61 — it would have paged at "90% of quota" during hours that never passed 61%. The server-side aggregate has no such error, which is why this alert reads it directly.

The for: 5m sustain filters momentary downward data revisions: five consecutive evaluations at or above 80 means the hour is genuinely filling up. Both dev-par01 and prd-par01 exporters probe the same shared Azure resource; the max by (probe) collapses their two views into one series (no cluster or environment matchers, one page per event).

• Sibling alerts: 02-email-service-minute-quota-high.md (the 30/min 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 (the dimensioned acs-email-api series; this alert reads Azure's hourly aggregate instead).
• The hourly window is rolling: the total recedes as old minutes age out, so stopping the sender recovers the budget within the hour — there is no reset to wait for.