Packets drop when using Okta API endpoints, resulting in HTTP 5xx errors and timeouts on local or cloud-hosted servers. This occurs because API calls to Okta fail to return, causing connection drops. Performing specific network data collection steps allows Okta to identify the root cause of the service disruption.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Local network devices using Okta API
• API Access Management / OpenID Connect (OIDC)
• Okta Representational State Transfer (REST) API
• Packet drops or timeouts between Okta and servers

API calls to Okta endpoints return HTTP 5xx errors or fail to return at all, causing connection drops on local or cloud-hosted servers attempting to contact Okta.

Common 5xx Error Types and Causes

The following table describes the most frequently encountered HTTP 5xx errors and their likely causes when communicating with Okta API endpoints.

NOTE: If any of these response codes occur consistently, check the Okta Status page for active service disruptions before beginning network-level diagnostics. Intermittent 5xx response codes may indicate packet loss or routing instability along the network path to Okta.

How does Okta investigate connectivity issues?

Review the Okta Status page for any active service disruptions to assist with network packet loss issues between Okta API endpoints and hosted systems.

Perform the following networking-level troubleshooting steps to determine the scope of the issue:

1. Isolate the Domain: Test the Okta default domain (https://<subdomain>.okta.com or https://<subdomain>.oktapreview.com or https://<subdomain>.okta-emea.com) to see if the issue is limited to the Custom Domain.
2. Verify Network Stability: Confirm if other websites or online applications are accessible from the same host.
3. Test Proxy Layers: Bypass any local proxy servers or antivirus software to determine if they are intercepting and dropping traffic.

What diagnostic data is required for Okta Support?

NOTE: It is recommended to work with the network team or vendor to obtain this information.

Provide the following information to Okta Support to assist with the investigation.

• Org Identification: The Okta OrgId and cell affected by the issue.
• Application Context: A full description of the application.
• Integration Type: The kind of integration in use (Security Assertion Markup Language (SAML), OIDC, Custom API Client).
• Environmental Details:
  • Hosting Location: Specify if the service is local/private or hosted in a cloud provider (AWS, Azure, Google Cloud).
  • Custom Domain Usage: Confirm if the integration uses a Custom Domain or the default Okta subdomain. 
• Observation & Reproducibility:
  • Describe how the error was observed and its frequency.
  • State whether the issue can be reproduced on demand.
  • Clarify if the failure is limited to a specific URL or affects all URLs in the Okta Org.
• Failure Metadata: The exact timestamp (including timezone), the specific failed URL, and the Public IP address of the requester.
• Success Comparison: Provide 1–3 successful request logs with timestamps (including timezone) to help identify intermittent patterns.
• Connection Metadata: Provide the user agent, public IP address, and port number for the failed request.

NOTE: Use the ifconfig web page to obtain the IP address.

• Network Topology Diagram: Provide a diagram of the network path from the client to the public internet edge.

  • Include: All active network devices from the client (where the Okta request originates) to the edge device (where the packet reaches the public internet) and a known working path for comparison.
  • Exclude: Any devices unrelated to Okta traffic.
  • NAT Mapping: Document both the internal IP (before NAT) and public IP (after NAT) for every translation device.

What diagnostic output and logs are required from the client and edge device?

Collect and provide the following diagnostic output and logs for Okta Support.

Trace the Network Path

Identify where packets are being dropped between the server and Okta.

• Windows: tracert <subdomain>.okta.com
• Linux/Mac: traceroute <subdomain>.okta.com

Verify DNS Resolution

Identify where packets are being dropped between the server and Okta.

• nslookup <subdomain>.okta.com or dig <subdomain>.okta.com

Analyze Latency with MTR

Run this command for three minutes to capture a stable sample of packet loss.

• mtr -P 443 -T <subdomain>.okta.com
• mtr -P 443 -T <custom_domain> 
• mtr -P 443 -T <AWS IP addresses from DNS resolution output>

Packet Capture (PCAP) Requirements

Capture a Packet Capture (PCAP) from the affected device and the network edge device (the furthest network device before accessing the internet and Okta), including the following details, making sure to include an analysis from the network engineering team or vendor team:

• PCAPs for both a working and a non-working scenario.
• Identify where the user collected the packet from and the collection method.
• IP address and port information (provide the IP address before and after NAT if applicable).
• If the user applies a capture filter, provide the filter details.

HTTP Archive (HAR) File

An HTTP Archive (HAR) file or any browser logging for both working and non-working scenarios.

Application Logs or Screenshots

Include application logs or screenshots that demonstrate failures and successes, including timestamps (including timezone).

NOTE: Okta investigates the cause of the service disruption using the provided information.

Related References

• Locating the Okta OrgId
• List of IP Addresses that Should be Allowlisted for Inbound Traffic
• Exporting Browser Log Files for Troubleshooting
• ERR_HTTP2_PROTOCOL_ERROR After Successful Authentication