Eight admin portals in one weekly email

The situation

The project folder does not document the starting point. No README, no documentation, no meaningful history. What was done before, how often something was missed, or what an expired certificate cost is nowhere in the code.

All that can be derived is what the system replaces: eight sources, each with its own portal view. That this checking was previously manual is plausible — it is not evidenced.

The approach

The service runs as a function on a schedule: early Monday, once a week. A second, key-protected entry point allows a manual run for testing.

An orchestrator first obtains two access tokens through the managed identity — no passwords live in the application. It then calls seven specialised collectors, each of which knows exactly one source and maps its result onto three uniform data structures. Queried are: app registration secrets, certificates and signing certificates; certificates and secrets from the key vault; TLS certificates from the app service; service health events and retirement notices through Resource Graph; message centre announcements; and a public updates feed, filtered by keyword for retirements and breaking changes.

Each collector runs with its own error handling: if a source fails, the error is collected and surfaced in the report as a warning — the email goes out regardless. Findings are graded against thresholds, assigned an owner, and rendered into a self-contained HTML page with summary tiles and three tables.

Where it could have gone the other way

Ownership — “who is responsible for this certificate” — is deliberately not pulled from the directory, but from a hand-maintained file.

The obvious route would have been to read the technical object owners recorded in the directory via the API. The header comment of the relevant module explains why that was rejected: distribution lists and shared mailboxes cannot be recorded as owners there at all — and an owner entry would simultaneously grant rights to manage the credentials.

The decision therefore separates “who do we notify” from “who may change this”, and prevents a notification requirement from silently widening permissions.

The price is named explicitly: the mapping has to be maintained by hand and goes stale if nobody touches it. If the file is missing, the column stays empty and the report runs anyway — a missing entry does not take anything down.

The result

18 modules, around 1,385 lines, the largest of them the HTML renderer. Eight read-only data sources, one delivery path, two entry points plus a local preview script that produces the same report without sending it.

Deliberately reporting only: the system renews nothing, rotates nothing, opens no tickets. Every response is manual.

Limits stated openly, and they are honest: there is no state. Every run starts from zero — no acknowledgement, no “already handled”, no escalation on non-response. The same item appears every week, unchanged, until the problem is fixed. The weekly cadence also means a certificate that becomes critical on Tuesday surfaces on Monday; the warning window softens that, but it is a setting, not a mechanism.

And whether an item is “action required” or “informational” is decided by keyword lists. That will predictably misclassify in both directions — a person still has to read the report, not just the traffic light.