Operating rhythm

A recommended weekly, monthly and quarterly cadence for keeping an IGA deployment healthy — and what "healthy" actually looks like as a number on each surface.

Identity-governance deployments are rarely lost in year one. They are lost in year three, when whoever configured it has moved on, the estate has drifted, and nobody has looked at the parts that do not shout. This page is for whoever inherited it.

⚠ This is a recommendation, not a feature.

The platform does not enforce this cadence, will not nag you if you skip a month, and has no concept of "your quarterly review is due". Every check below is a surface you visit deliberately. If a rhythm suits your organisation better, use that one — what matters is that these surfaces get looked at by a person on some regular basis, because several of them fail quietly by design.

Three things that look like health and are not

Before the cadence, the reason for it. Three shapes recur across every surface here, and all three read as green:

An empty queue can mean nothing is being attempted. A failed-jobs queue at zero is either a well-run estate or a connector that stopped trying. The count alone cannot tell you which.

A silent detector and a broken detector look identical. A check that finds nothing reports nothing. A check that crashed on its first row also reports nothing. If you read finding counts, those are the same number.

A green tick can outlive the failure it should have reported. This is the one the platform actively defends against: the backup surface only shows a last-successful timestamp when the most recent attempt succeeded, never a comforting date from a success three weeks ago that has since been followed by failures. Assume other tools in your stack do not make that distinction, and check the last attempt, not the last success.

The cadence below is built around looking at the things that do not shout.

The cadence

Weekly

The decision inbox

The number to read is the count of open decisions — approvals and access-review items where a named person has to choose. That count deliberately excludes reconciliation drift, which is a bulk-triage lane with its own workflow and its own, usually much larger, number. Conflating them produces a four-figure badge for seventeen real decisions, which trains everyone to ignore the badge.

Healthy is a number you can clear in one sitting, and — more importantly — no item past its deadline. An overdue review item is not merely late: review rules can carry an automatic action on deadline, so an ignored queue eventually starts revoking, disabling or suspending on its own. The point of looking weekly is to make those actions deliberate rather than a consequence of nobody looking.

A large drift number next to a small decision number is not an alarm. It is reconciliation doing its job and waiting for a bulk decision.

Failed provisioning jobs

A healthy failed-jobs queue is not zero. Real target systems rate-limit, time out and go down for maintenance; those failures are recorded honestly rather than swallowed. What matters is the mix and the age.

Failures fall into three retry classes, and reading the queue means reading which class you are looking at:

• Transient — the target errored, was unreachable, or rate-limited you. There is nothing in your configuration to fix; these retry without any change, and a healthy queue accumulates some and drains them.
• Configuration-shaped — a broken mapping, a lookup that returned nothing or several things, a required attribute the identity does not have. Retry on these is gated behind an actual configuration change: the platform refuses a retry when the configuration hash is unchanged, precisely so "click retry until it works" is not a strategy. These are the ones that need a person.
• Policy-blocked — a governance gate refused the write. Retry will never help; the remedy is to change the policy or record the job as won't-fix with a justification.

The platform's own degraded threshold is more than ten failed jobs, but the more useful weekly reading is simpler: does the queue drain? A configuration-shaped failure that is still there next week is the signal. The same transient failure count week after week, with different jobs in it, is normal operation.

Monthly

Are the detectors running, or merely quiet?

Each advisor check carries its own health fields alongside its configuration: when it last scanned, its last error, and a consecutive-failure count. Read those, not the finding count. A detector that has failed on every pass for three weeks produces exactly the same "no findings" as one that is genuinely happy. Once a month, look for a non-zero consecutive-failure count or a recent error, and treat a failing check as more urgent than any finding it might have reported.

Two configuration traps worth re-checking at the same time: a detector whose interval was set to "on demand only" will never fire on its own again, and a detector someone disabled during an incident stays disabled.

One year-three-specific note: a tenant that has gone live keeps setup-phase findings — "no approval rule configured yet", "this entitlement has no grants" — out of the working inbox, because on a fresh tenant those are configuration steps rather than decisions. If your inbox suddenly fills with setup-shaped findings, the tenant has been flipped back to setup mode rather than the estate having collapsed overnight.

Scheduler sweep health

Roughly two dozen background sweeps run on their own cadences, from once a minute (expiring time-boxed elevations) through every five minutes, half-hourly and hourly, to daily (backups, the full reconciliation safety net, snapshots). Each records every pass durably, so "is one stuck?" has an answer.

Healthy has a precise shape here:

• Erroring should be zero. A sweep counts as erroring after three consecutive failures — one bad pass is noise and does not count.
• Overdue means genuinely late, not idle: last run older than that sweep's own expected interval times a grace factor of two. A daily sweep is not overdue at 25 hours.
• Never run is not unhealthy. A tenant with no provisioning batches will never trigger the batch-archive sweep. Expect a handful of never-run entries permanently, and do not chase them.

Backup verification

Check the most recent attempt, not the last success. The surface is built so that a failed latest attempt shows no success timestamp at all rather than an older, reassuring one — so a blank where you expected a date means the last run failed, not that backups were never configured. An explicitly untracked state means your plan is not eligible for scheduled tenant backups, which is a different conversation entirely.

Two things the product does not do for you, and which belong in your own runbook: verifying that a backup restores, and holding a copy outside this platform's blast radius. A backup nobody has ever restored is a hypothesis.

Quarterly

Coverage, and the hollow green

Access-review coverage sorts every governed object into three buckets, and the third is the one that earns the quarterly slot:

• Covered — a review rule matches the object and the resulting reviewer chain resolves to a real person.
• No rule — nothing reviews this. An honest, visible gap.
• No owner — a rule matches, but the review resolves to nobody. This is the hollow green: a coverage metric that only counted "has a rule" would report these as covered, and you would discover the truth when a campaign spawns zero items.

Work the no-owner bucket first. It is the difference between a review programme and a review programme on paper. Ownership coverage reads the same way: the resolution cascade tries explicit owners, then buckets, then application and system owners, then organisational and manager fallbacks — and when it reaches the end it reports a gap rather than inventing a plausible owner. That terminal bucket is your quarterly work list.

Connector health

The stale-connector check defaults to flagging a system that has not synced in thirty days. Treat that as a floor, not a target: a connector on a four-hour schedule that last synced three days ago has been broken for a long time before the detector fires. Once a quarter, read each system's last sync against its own schedule, not against the detector threshold.

While you are there, confirm the safety limits are still as you left them. The mass-revoke breaker defaults to aborting a reconciliation run that would remove more than a quarter of a connector's live assignments, with a floor of ten so small cleanups are never blocked, and it fails safe — a trip keeps the access rather than removing it. Two things to look for: that it is still enabled, and that no per-connector override has quietly widened it. The one-shot "allow the next run" bypass is consumed once by design; if someone is arming it repeatedly, the finding is not the threshold.

Does the estate still match the role model?

The sharpest single number for year three: in-target assignments with no expected source — access that exists in a target system and is not explained by any policy, role, request or attestation. It is exactly the residue that accumulates when a role model stops being maintained.

The platform sorts that residue into four actions: fits an existing role, suggests a new role, is genuinely individual, or should be removed. You are not looking for zero. You are looking for a number that goes down quarter on quarter, and for the "should be removed" bucket not to be growing.

When to call your partner

Some findings are not configuration errors and should not be treated as your problem to grind out:

• A detector erroring across more than one cycle that you cannot explain from its error text. That is usually a data shape nobody anticipated, not something you misconfigured.
• The mass-revoke breaker tripping more than once in a quarter. One trip is a healthy save. Repeated trips mean the expected-access model is wrong, and the fix is upstream in policies or roles — never a habit of bypassing.
• Coverage that will not move because the objects genuinely have no owner anywhere in your organisation. That is an org-design problem, and the useful conversation is about who should own that class of thing.
• Migration drift or database errors on the core health group. Nothing downstream is trustworthy while that is amber.
• Anything that stays amber across two consecutive monthly checks after you have fixed the obvious cause.

What this page is not

There is no service-level agreement behind these cadences, and no public status page. The health surfaces described here are your own tenant's telemetry, not a hosted uptime commitment.

And the advisor does not replace an operator. Detectors surface findings and, in a few narrowly-scoped cases, take a defensive action to limit damage; deciding what a finding means for your organisation is still a person's job. That is the design, not a gap — a tool that quietly resolved these would eventually resolve one wrongly, and you would find out in a review.

Further reading:

• Platform health — the surfaces this rhythm visits, and what each signal group rolls up
• Failed jobs queue — the retry gate and the failure taxonomy in full
• Platform advisor — how detectors are configured per tenant
• Reconciliation — expected versus actual, and what drift means
• Roles and role mining — turning ungoverned access back into a role model
• What we don't claim — the wider honesty posture these surfaces follow