D365 PortalFinance and Operations telemetry can grow a lot, fast. A misconfigured integration or an exception loop generates a normal week's volume in hours. Without a cap, that becomes an Azure bill nobody saw coming.
The problem
Telemetry cost is proportional to ingested volume, and the volume is not controlled by the portal: it is controlled by what happens in your environment. A spike is not a system failure, it is the system doing its job while something goes wrong in D365.
The approach
Each plan carries a daily ingestion cap, enforced on the Azure platform rather than by an interface check. Starter takes 0.5 GB per day and Pro takes 2 GB. When consumption approaches the cap, an alert rule can warn you: by default, at 80 %.
Cut off or pay overage
There are two possible behaviours at the cap, and the choice is yours.
| Option | What you gain | What you lose |
|---|---|---|
| Cut ingestion off | The bill is predictable. You never pay more than you contracted. | You lose the rest of the day's telemetry, exactly when something odd is happening. |
| Bill overage | No gaps in the data. You can investigate the spike in full detail. | 6 USD per additional GB, and the spike that drives the cost is precisely the one you did not expect. |
If you are debugging a production problem, overage is usually cheap compared to going blind. If the environment is stable and the budget is rigid, cutting off is the sensible call.
Retention
Retention defines how long ingested data is kept: 30 days on Starter and 90 on Pro. It is also the real ceiling of the range selector: asking for 30 days on Starter works, but there is nothing further back. If you need to keep a specific incident beyond that window, export it to CSV while it is still available.