Skip to content

Monthly Platform Health Check

A monthly check shows whether the platform is healthy and compliant, and whether the service is being delivered as agreed. It gives the platform team a fixed moment to look at everything that no alert covers, and it gives the customer a report to discuss in the tactical meeting.

The check is the same in both operating models. In the managed model the platform team (XMMS) produces the report and the customer reviews it. In the self-managed model your own platform team produces it and reports to its stakeholders (security officer, service owner, management).

Examples, not settings

The checks below come from reports used on real managed platforms. Thresholds, lead times and subscription names are examples. Set your own in your service levels.

When and who

Item Suggested value
Frequency Monthly, in the first week after month end, for the previous calendar month
Producer The platform team
Reader <service owner>, <security officer>, workload team leads who want it
Where it is stored <documentation space>, one page per month, same structure every time
Follow-up Every finding becomes a work item, or is accepted with a reason. Review open items in the next report

Automate the data collection when you can (a script or a scheduled pipeline that writes the report). The structure matters more than the tool: a report that is the same every month makes trends visible. A pattern for the automation is in Producing the report.

What to check

1. Platform health

Check What to look at What is normal
Application Gateway availability Availability percentage per gateway over the month, and the current status Available, at or above your availability target
WAF policy mode Mode of every WAF policy, per platform environment Prevention. A policy in Detection needs a recorded reason
Azure Firewall health Average health percentage per firewall (canary and prod) At or above your availability target
Virtual WAN, VPN and ExpressRoute connections Connection state and whether traffic flows Connected, with traffic. See Incident management for why state alone is not enough
Hub alerts Alerts fired during the month, by severity, and how many were actionable. Compliance of the alert policies No unexplained alerts, and the alert initiatives are compliant. Noisy rules get tuned (Monitoring rules, How alerting works)
Drift Result of a hub run in Plan mode (Operating responsibilities) No changes. Every change you did not commit is drift. For spokes, use the report of the spoke drift detection

Compare canary and prod. A difference that nobody asked for is a finding.

2. Compliance and security

Check What to look at
Secure score Defender for Cloud secure score per platform subscription, and the trend against last month
Top actions The three recommendations that raise the score most, with affected resource counts
Regulatory compliance Per assigned initiative (for example CIS and ISO 27001): number of non-compliant controls, percentage compliant, and the non-compliant policies with the number of resources. See Governance
High-severity recommendations All Defender for Cloud recommendations with severity High, per subscription
Policy exemptions Exemptions that expired or expire next month (Policy assignments)
Secret and certificate expiry App registrations and service principals with a secret or certificate that expires within <n> days (for example 60). Include the platform's own deployment identities and the spoke identities (Change spoke). A weekly secret watcher catches expiry between reports
Advisor New Azure Advisor recommendations, turned into backlog items

3. Service management

Check What to look at
Incidents Each incident closed in the month: identifier, title, resolve time (hours and days) and severity, plus the average
Standard changes Each standard change closed in the month: identifier, title, resolve time, plus the average
Comments Why a resolve time was long. Mark time spent waiting for the customer or for a platform update separately, so it does not distort the average
Severity 1 and major incidents Link to the post-mortem for each one
Open items Work items carried over from earlier reports

Resolve times are only comparable when you measure them the same way every month. Decide from which moment to which moment you measure, and write it in the service levels.

4. Managed VMs (only if your platform offers them)

See also the weekly patch check in Managed VM module.

The MCP core does not deploy or patch VMs for workload teams (Responsibilities). If your platform adds a managed VM offering on top, check monthly:

Check What to look at
VM inventory List of managed VMs, by environment. Compare with the configuration
Patching Per VM: patch status, pending, failed, installed and excluded patches, and date of the last installation. You can only read the status of VMs that are running. Create an incident for every failed patch run
Backup Per VM and per backup solution (backup vault and Recovery Services vault): last backup status and time. Count the VMs per vault and compare with the inventory. A VM without a backup is a finding

Producing the report

A pattern that works on managed platforms:

Step What
Schedule A pipeline runs on the first days of the month and takes the previous month as the default period, with a parameter to run another month or a single platform
Access One read-only service principal per tenant, with read rights over the platform subscriptions, for example at the root management group (for policy states, secure score and recommendations) and, where possible, read access to app registrations (for secret expiry). If you have no rights for secret expiry yet, say so in the report instead of leaving the section out
Collection Scripts query Azure Resource Graph, Defender for Cloud and the ticket system, and fill the tables of the report template: resolve times, secure score, recommendations, secret expiry, Application Gateway health and WAF mode, firewall health
Publishing The report is a page in the wiki that the customer can read (for example one page per month under Reports / Monthly checks). Where the customer has its own DevOps organisation, publish it there
Review A person reads the report, adds the comments (for example why a resolve time was long) and shares it. The service owner leads the follow-up

Take action on the outcome: a secure score below your threshold (for example 80%) means look at the recommendations in the portal, discuss with the service owner whether the organisation needs to act, and create work items. A secret that is about to expire is rotated by its owner, or by the platform team if you have the rights (Secret watcher).

Keep the credentials of the reader identities in a secure store, and rotate them on a schedule: they are secrets that expire too.

Report structure

Use the same headings every month:

# Monthly Platform Health Report - <month> <year>

## Executive summary
Period, date generated, three to five sentences: what is fine, what needs attention, decisions needed.

## Platform health
Application Gateway availability, WAF policy mode, Azure Firewall health, connections, alerts, drift

## Compliance and security
Secure scores, top actions, compliance per initiative, high-severity recommendations,
exemptions, secret and certificate expiry

## Service management
Incidents, standard changes, resolve times, post-mortems

## Managed VMs (optional)
Inventory, patching, backups

## Findings and actions
Table: finding, severity, owner, work item, due date, status

Keep customer data out of shared copies

A monthly report names subscriptions, accounts, applications and secrets. Store it where only the people who need it have access, and strip the details before you use a report as an example elsewhere.

Recurring findings

These findings came back in most reports. Look for them first.

Finding What to do
Guest accounts, or disabled accounts, that still hold read, write or owner permissions on Azure resources The identity team removes them. Access is meant to come from groups and PIM (Access and PIM), so a direct assignment that nobody can explain needs an owner or removal
Low secure score on the management and identity subscriptions Pick the top three actions each month, and plan them. Do not try to fix everything at once
The same non-compliant policy on every platform subscription Fix it once in code, or record a time-limited exemption with a reason
Secrets and certificates close to expiry, often on app registrations that nobody remembers Find the owner. Rotate, replace by federated credentials, or delete the registration
Storage container that holds activity logs is publicly accessible, or a Defender plan that is not on Fix in the platform code or configuration, then check the next report
Long resolve times that are caused by waiting for a platform release Track them as a separate category (Service level management)
Patching fails on one VM again and again Look at the VM (disk space, agent, pending reboot), not at the schedule