## 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
```text
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