🚨 Microsoft Teams Error: 'Directory_QuotaExceeded' — Cause, Fix, and Troubleshooting Guide

What this error means

Directory_QuotaExceeded is returned by Microsoft Graph when a create would push a principal past a directory object quota. Because a Team is backed by a Microsoft 365 group — a directory object — creating teams counts against the same quota as creating groups. A non-admin user can create only a limited number of directory objects (the default per-creator quota is around 250), and the tenant itself has an overall object cap. When automation runs as an ordinary user or a low-privilege service principal and creates a team per request, it eventually hits the ceiling. Graph returns HTTP 403 (and in some create paths HTTP 400).

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "error": {
    "code": "Directory_QuotaExceeded",
    "message": "The directory object quota limit for the Principal has been exceeded. Please ask your administrator to increase the quota limit or delete objects to reduce the used quota.",
    "innerError": {
      "date": "2026-07-12T12:41:55",
      "request-id": "9c22ab00-4411-4d1e-b3a2-77ee99cc1200",
      "client-request-id": "9c22ab00-4411-4d1e-b3a2-77ee99cc1200"
    }
  }
}

The key word in the message is “Principal”: the quota is counted against whoever created the objects, not against the team being created.

Warning signs

• POST /groups or POST /teams returns 403 with code Directory_QuotaExceeded.
• A provisioning service that ran fine for months starts failing once its cumulative created-object count grows.
• The same create succeeds when run by a Global/Directory admin but fails under the automation identity.
• Deleting a few unused groups temporarily unblocks creation, then it fails again.
• The failing identity has created hundreds of groups/teams over its lifetime.
• Bulk onboarding that creates a team per customer or per project stalls at a round-ish number of objects.

Measuring the limit

Count the objects the failing principal has created. createdObjects is the navigation that lists them:

# For a user principal
curl -s -X GET \
  "https://graph.microsoft.com/v1.0/users/USER_ID/createdObjects/\$count" \
  -H "Authorization: Bearer $GRAPH_TOKEN" \
  -H "ConsistencyLevel: eventual"

For a service principal, count via its createdObjects navigation the same way:

curl -s -X GET \
  "https://graph.microsoft.com/v1.0/servicePrincipals/SP_ID/createdObjects/\$count" \
  -H "Authorization: Bearer $GRAPH_TOKEN" \
  -H "ConsistencyLevel: eventual"

Break the created objects down by type so you can see how many are groups/teams versus other directory objects:

curl -s -X GET \
  "https://graph.microsoft.com/v1.0/users/USER_ID/createdObjects?\$select=id" \
  -H "Authorization: Bearer $GRAPH_TOKEN" \
  | jq -r '.value[]["@odata.type"]' | sort | uniq -c

Find candidate groups to clean up — for example unified groups with no recent activity that your team owns:

curl -s -X GET \
  "https://graph.microsoft.com/v1.0/groups?\$filter=groupTypes/any(c:c eq 'Unified')&\$select=id,displayName,createdDateTime" \
  -H "Authorization: Bearer $GRAPH_TOKEN" \
  | jq -r '.value[] | "\(.createdDateTime)\t\(.displayName)\t\(.id)"' | sort

Limits and pressure causes

• Per-creator quota reached. The user or service principal has created more directory objects than its quota allows (default roughly 250 for a normal user).
• Automation runs as a low-privilege identity. A per-request “create a team” job accumulates ownership of thousands of objects under one principal.
• Soft-deleted objects still counting. Recently deleted groups/teams in the 30-day recycle window may still occupy quota until purged.
• Tenant object cap. The directory as a whole is near its maximum object count, independent of any single creator.
• No cleanup lifecycle. Abandoned teams are never archived or deleted, so the created-object count only grows.

Remediation

There are three durable fixes; pick based on why the quota was hit.

Raise the creating principal’s quota by assigning it a directory role with a higher object quota (for example a Directory-level admin role), so the per-creator limit no longer applies at the user default:

# Assign an appropriate admin/Directory role to the automation principal
# via Entra roles so its per-creator quota is raised. Scope it tightly.

Reclaim quota by deleting truly unused groups/teams, and remember that deleted directory objects sit in a recycle bin for ~30 days. Permanently remove them to free quota sooner:

# Soft delete
curl -s -X DELETE "https://graph.microsoft.com/v1.0/groups/GROUP_ID" \
  -H "Authorization: Bearer $GRAPH_TOKEN"

# Purge from the directory recycle bin to reclaim quota immediately
curl -s -X DELETE \
  "https://graph.microsoft.com/v1.0/directory/deletedItems/GROUP_ID" \
  -H "Authorization: Bearer $GRAPH_TOKEN"

Best practice for automation: create teams under an application/service principal that holds appropriate Group/Team creation privileges and a higher object quota, rather than under an ordinary user identity. Combine that with a lifecycle policy (Microsoft 365 group expiration/archival) so abandoned teams are reclaimed automatically instead of consuming quota forever.

Capacity headroom

• Design for the ceiling. Any “create a team per request” pattern will hit a quota eventually — plan a lifecycle before you deploy it.
• Purge, do not just delete. Soft-deleted groups can keep counting for ~30 days; purge from directory/deletedItems to reclaim quota now.
• Use a service identity with headroom. Run bulk provisioning under a principal that has a raised quota, not a personal user account.
• Automate cleanup. Apply group expiration/archival policies so inactive teams are reclaimed without manual work.
• Watch the tenant cap, not just the creator. If per-creator counts look fine, you may be near the overall directory object limit — check with an admin.
• Monitor createdObjects growth. Track the count over time and alert before it approaches the quota, not after creates start failing.

Related capacity errors

• 403 Authorization_RequestDenied
• 429 Too Many Requests
• Bad Request / Invalid Request