How to find inactive users in Azure DevOps

Why inactive users cost real money

Azure DevOps bills per user, per access level. Two levels carry a charge: Basic at about $6/user/month and Basic + Test Plans at about $52/user/month. Stakeholder access is free, and users covered by a Visual Studio subscription get Basic-level access without consuming a paid seat.

An inactive user on a paid seat is money leaving every month for nothing. One forgotten Basic seat is ~$72/year; a forgotten Basic + Test Plans seat is ~$624/year. Across a real org, dozens of these accumulate — people who left the company, moved teams, or were provisioned "just in case" and never onboarded. Nobody is watching the meter, so the seats quietly renew.

Where Azure DevOps keeps the last-access date

The record you need lives under Member Entitlement Management. In the portal, open Organization settings → Users. The Users grid lists every member, their access level (Stakeholder, Basic, or Basic + Test Plans), and a Last access date — the last time each person actually used the org.

Two patterns matter most here:

• A stale last-access date — the user exists and has a paid seat, but hasn't touched the org in months.
• No access at all — the user was invited and licensed but never signed in. These "never-accessed" seats are pure waste; the person may not even know the account exists.

How to read the dates: the three buckets

Sort your paid users by last-access date and sort them into three buckets. Two are firm; one needs a quick human check.

The 6-plus-months and never-accessed bucket is where you act first. There's no scenario where a paid seat that hasn't been used in half a year is earning its cost. The 3-to-6-month bucket is an early warning — those seats are drifting toward firm waste, and catching them now saves another two quarters of spend.

Revoke or keep? A simple decision

Not every inactive user should be deleted. The right move depends on whether the person still needs any relationship with the org:

• Left the company or the project entirely → remove the user. You stop paying and tidy up access at the same time.
• Still around but no longer doing paid work (a manager who only reads dashboards, say) → downgrade to the free Stakeholder level. They keep visibility into work items and dashboards; you stop paying for Basic.
• On a Visual Studio subscription but assigned a paid Basic seat → drop the paid seat. Their VS subscription already entitles them to Basic-level access, so the paid seat is a double charge.
• Genuinely returning soon (parental leave, sabbatical) → note it and leave the seat, or downgrade to Stakeholder in the interim.

Crucially, none of these actions is destructive. Removing or downgrading an access level does not delete a user's work items, commits, or history. It only changes what they can do going forward — which is why acting on the firm-waste bucket is genuinely low-risk.

Doing it by API vs. doing it automatically

You can pull this data yourself. The Member Entitlement Management API returns every user's entitlement, access level, and last-access date, so you can script a quarterly export and reconcile it in a spreadsheet: flag anyone over six months, cross-check who's on Basic + Test Plans, and confirm who has a Visual Studio subscription. It works — but it's a recurring chore, and the reconciliation (especially spotting VS-subscriber double-charges) is where manual reviews tend to slip.

The alternative is to point a tool at the org and get the whole picture in a few minutes: every paid seat, its tier, its months of inactivity, whether it's a never-accessed seat, and a recovery estimate — refreshed whenever you want to check. That turns a quarterly spreadsheet marathon into a glance.