Microsoft is clear that this is not real-time monitoring. It shortens the review window for specific metrics on specific resources from a day to an hour. For admins who have been working with daily numbers, that is still a useful change.
Why daily alerts weren't enough
Monitor alerts have always worked on daily data. An earlier write-up from CRM Minds summed up the old model: alerts are evaluated every 24 hours, not in real time. All metrics in the Monitor area are 24-hour aggregates. When you create a new alert rule, the system does an on-demand evaluation immediately. After that, it runs once per day.
A daily check works for spotting trends, but it's slow when a production flow breaks at 9 a.m. Microsoft's own release planning pointed this way. The 2026 release wave 1 plan says you can configure alerts to run reliably every 24 hours, and you can set them up with a 1-hour evaluation frequency. This frequency helps teams catch degradations early. It describes the feature as an enhancement to the Create alerts for your resources feature, which started with 24-hour health metric aggregates.
Summary: Monitor alerts used to be daily. You can now opt individual rules into an hourly cycle.
How hourly alerts work
The main control is the alert rule's Data review period setting:
- Default behaviour: Monitor metrics refresh every 24 hours, and alerts are evaluated after each new daily aggregate is produced.
- Hourly behaviour: Set Data review period to 1 hour and Monitor turns on hourly aggregation for that one metric on that one resource. The rule is checked after each new hourly aggregate arrives and can fire every hour while its condition is met.
- Scope: Only the selected resource and metric become hourly. Other metrics on the same resource stay on their current aggregation.
Microsoft's Learn documentation calls these "low-latency alerts" and adds two details the blog leaves out:
- No instant first check. Standard 24-hour rules run an on-demand evaluation as soon as you create them. Hourly rules don't, because no hourly data exists yet. Don't panic if nothing appears straight after you save the rule.
- Resource scope only. Hourly rules have to be resource-scoped. You can't set an environment-wide rule (for example, "all canvas apps in Production") to hourly.
Supported products and metrics
According to the announcement, these combinations are supported at launch, with more promised later but no timetable given:
| Product | Supported hourly metrics |
|---|---|
| Copilot Managed Runtime apps | Time to interactive, App open success rate, App session count, Data request latency, Data request success rate |
| Canvas apps | Time to interactive, App open success rate, Data request latency, Data request success rate |
| Model-driven apps | App open success rate |
| Code apps | Time to interactive, App open success rate, Data request latency, Data request success rate |
| Cloud flows | Success rate |
| Agents | Agent session success rate |
Microsoft's FAQ makes a point worth knowing for canvas and code apps: Time to Interactive alerts only measure the app's start screen. You can't point an alert at a particular screen deeper in the app.
Desktop flows are missing from the list, even though they're covered by the standard daily alerts. If an RPA bot is your critical workload, you're still on daily checks for now.
Setting up an hourly alert for a Power Platform resource
Requirements first. You need tenant-admin or environment-admin rights, the resource must be in a Managed Environment, and you must use the new Power Platform admin center. The Managed Environment rule isn't new. ServerSys pointed out when custom alerts first appeared that alerts require Power Platform managed environments, so you'll need to have that governance capability enabled to use them.
The steps:
- Sign in to the Power Platform admin center and open Monitor.
- Pick the product (Power Apps, Power Automate or Copilot Studio) and select the resource to open its resource pane.
- Select + New alert rule in the upper-right corner. This option only appears for resources in Managed Environments.
- Check that the prefilled Product, Product type, Environment and Resource are correct, and that Scope is set to Resource.
- Name the rule. Under Metric, choose a supported metric. Supported metrics have a clock symbol next to them in the selector.
- Set Data review period to 1 Hour.
- Set the Operator (Is Under, Is Over or Equals), the threshold, the Severity and the Notification type, then save.
Setting up an hourly alert for a Copilot Managed Runtime app
- In the Microsoft 365 admin center, go to Apps > All Apps.
- Select the app to open its details pane.
- Open the Monitor tab and select + New alert rule.
- Choose a metric and set Data review period to 1 hour.
- Set the operator, threshold, severity and notifications, then save.
Microsoft says only Power Platform admins and Global admins can create and manage these rules in this admin center. Its Microsoft 365 admin documentation adds that AI admins, AI readers and Global readers can see metrics and alert details but can't create or change rules.
Summary: The steps match across both admin centers. The prerequisites don't: Power Platform needs a Managed Environment and resource scope, while the Microsoft 365 admin center restricts who can create rules.
Investigating after an alert fires
Go back to the same resource pane and set the chart's Review period to 1 hour. Note the naming: the chart's Review period and the rule's Data review period are separate settings. The first changes what you see on the chart. The second controls how often the rule aggregates data and runs.
Limits on the hourly view:
- 24 hours only. The hourly chart shows the last day and nothing older.
- No hourly export. Microsoft's FAQ says Monitor's data export only includes daily aggregates, so you can't send hourly data to your own data warehouse.
- Summaries stay daily. The product list page and the metric summaries on the left of the resource pane still show 24-hour figures while you're looking at the hourly chart.
- The banner shows past firing only. A banner above the chart means the alert fired at some point in the time range shown. It doesn't mean the alert is still firing, that the problem is still open, or that there's an outage right now.
Notification behaviour
The Learn FAQ explains what happens after a firing. You get an email as soon as a low-latency alert fires, then a reminder every four hours while the problem continues. Reminders stop when the issue resolves or after seven days, whichever comes first. If the problem returns after it resolved, a new email goes out. Microsoft also suggests making sure your mail system accepts messages from its Power Platform no-reply senders, so the alert doesn't end up in quarantine.
The main gap is automation. Power Platform has a preview "When an alert fires" trigger on the Power Platform for Admins V2 connector. It can route alerts through Power Automate to Teams, Azure DevOps, ServiceNow and other destinations. Hourly rules can't use it yet. Only 24-hour rules can opt in, and Microsoft says it expects hourly support by January 2027. Until then, hourly alerts arrive by email only.
Limits: the blog and the docs disagree
| Question | Blog announcement | Power Platform Learn page |
|---|---|---|
| Hourly rule limit | Up to 10 per experience; the two admin centers count separately | Up to 10 low-latency alerts per tenant |
| Rules per resource and metric | Not stated | One. You can't add a second rule with a different threshold or severity |
| Disabled rules | Not stated | Turned-off hourly rules still count toward the 10 |
| Overall limit | Not stated | 10 hourly plus 50 daily, 60 in total |
These can be reconciled: 10 per tenant in Power Platform, plus a separate 10 in the Microsoft 365 admin center. Even so, go by the counter your own admin center shows.
The disabled-rule point matters in practice. Turning off an hourly rule doesn't free its slot, so delete rules you no longer need. One more inconsistency: a note elsewhere on the same Learn page still says Data review period is in preview and limited to code apps. That conflicts with the new low-latency section and looks like documentation that hasn't been updated yet.
Analysis: a useful but limited tool
With only ten slots, hourly alerts are a short list, not a way to watch everything. They suit:
- Revenue- or operations-critical flows, such as order intake or approvals, where a drop in success rate turns into a support backlog within hours.
- Front-line apps where an hour of slow Time to interactive means staff waiting around.
- Customer-facing agents, where Agent session success rate is the closest thing to a health check you get.
Base thresholds on each resource's normal pattern. A busy flow and a rarely used one need different thresholds. An app with few users can show big swings in hourly success rate because of one or two failed sessions. A threshold that's sensible for daily data could flood you with alerts at hourly granularity. The four-hour reminder cycle and the one-rule-per-metric limit cut down repeat emails but don't fix a badly chosen threshold.
Some advice is just general operations practice. This is preview software with mismatched documentation, no automation hook yet and only a day of hourly history. Don't rely on it alone to enforce a strict SLA. If you need minute-level detection or long-term records for audits, you still need proper telemetry, such as Application Insights, on the most critical workloads.
Even so, going from a day to an hour is a big improvement for teams that currently find out about a broken flow from users. Starting November 20, 2026, an admin can pick the three to five resources that matter most and know about a failure within roughly an hour.