Okta SCIM "deprovision failed" app returned 500

TL;DR

Retry the deprovision after checking the target app's health; the 500 came from the app, not from Okta. Okta reports what the target said.

Error

Deprovision failed: the target application returned HTTP 500

Steps

1. Check the target application's status page or health endpoint for an ongoing incident. Expected: you know if the app is down.
2. Look at the Okta System Log for the failed provisioning event; it captures the target's response detail. Expected: the target's error message in hand.
3. Retry the deprovision from the Okta user or app page once the target is healthy. Expected: the retry succeeds.
4. If the 500 persists on a healthy app, open a ticket with the app vendor including the System Log event ID. Expected: the vendor can reproduce from the log.

When to use

• Deprovision fails with the app returning 500
• The failure correlates with a target outage
• Retries during the incident all fail the same way

When not to use

• Okta itself errors (an Okta-side problem)
• The app returns 4xx (a request or data problem, not a server error)
• The deprovision partially succeeded (check the target state before retrying)

Tool compatibility

Okta SCIM provisioning to any target app. The 500 is the target's, not Okta's.

Variant phrasings

500 only for one user

That user's data trips a target bug. Retry after fixing or removing the offending attribute.

deprovision 500s but the user is gone from the target

The target processed the delete and then errored. Verify state before retrying to avoid duplicate handling.

Why it happens

Deprovisioning calls the target's API, and any target-side failure surfaces through Okta. The fix lives on the target side; Okta is just the messenger.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Z8HtuhxU5X8XrJgEkQ2hhQ