PDI is unusable: 504 snow_adc

[JakubGiza]

Hi ServiceNow Community,

My PDI shows as Online in the Developer Portal, but the instance has been almost unusable since yesterday.

Symptoms:
- Scripts - Background returns 504 Gateway Time-out / snow_adc
- Logout can also return 504
- Normal browser and incognito both affected
- Browser sometimes reports ServiceNow pages as unresponsive
- cancel_my_transactions.do says: “All transactions have completed, nothing to cancel”
- User Sessions list mostly shows already invalidated sessions
- Standard pages sometimes load, but the instance is extremely slow/unstable

/stats.do shows:
- Instance state: ONLINE
- Build: Australia
- Servlet free memory: 2%
- Default semaphore queue depth: 10
- Queue age: 12:58:37
- Currently waiting on session synchronizer: 10
- Mean time waited so far: 5:02:06
- OS load average: 45.22 / 55.10 / 92.30
- DB latency: 2
- Background scheduler workers idle
- Database pool online and not busy

Transaction Log only shows completed small REST/UI transactions. I do not see anything obvious to cancel from the UI.

It looks like the PDI is online but the backend node is stuck / memory-starved / blocked. Is there any way to recover this PDI or trigger a backend restart without resetting or wiping the instance?

I do not want to release/reset the instance because I have application work on it.

Thank you in advance

Jakub

[Dr Atul G- LNG]

Hi @JakubGiza 

If your ServiceNow Personal Developer Instance (PDI) has been stuck in the Refreshing state for more than 24 hours and is returning an HTTP 502/4 error, it is likely that the underlying infrastructure or node hosting your instance has encountered an issue.

Option 1 – Try Refreshing the Instance

1. Sign in to the ServiceNow Developer Portal.

2. Go to Manage My Instance.

3. Click the Refresh button (if available).

4. Wait for the refresh process to complete.

In some cases, the PDI may recover after a manual refresh.

Option 2 – Release the Instance and Request a New PDI

If your PDI continues to return an HTTP 502/4 error or remains stuck for more than 24–48 hours, I generally recommend releasing the instance and requesting a new Personal Developer Instance (PDI) from the Developer Portal.

Based on community experience, instances that remain in this state for an extended period rarely recover automatically.

Please note the following before releasing your instance:

• Provisioning times for new PDIs have increased significantly in recent weeks.

• Many community members have reported waiting 2–3 weeks or longer to receive a new instance, regardless of the selected release version.

• There have been multiple reports of PDI failures, provisioning delays, and general Developer Portal availability issues.

Unfortunately, no one can provide an exact timeline for when these issues will be resolved or when a new PDI will be provisioned.

For now, the best approach is to monitor your request status in the Developer Portal and be patient while waiting for your new instance to become available.

[JakubGiza]

Thank you so very much for all your tips. I've done some of them already, but reducing the number of scripts helped a bit.

Have a great day

[Tanushree Maiti]

Hi @JakubGiza 

A 504 Gateway Time-out during a Background Script typically indicates that the script execution exceeded the timeout limit enforced by the platform, browser, or proxy server. This often happens when processing large datasets or waiting for slow external integrations.

Recommended actions:

• Terminate the current job or transaction if it is still running.
• Clear the instance cache using cache.do.
• For scripts that process large volumes of data, avoid using the Background Scripts page. Instead, create a Fix Script (System Definition > Fix Scripts). Fix Scripts are trackable, can be monitored, and continue executing even if the browser session times out.
• Use setLimit() on GlideRecord queries whenever possible to reduce the number of records retrieved in a single execution.
• Process records in small, manageable batches (like 50–100 records per execution) to minimize execution time and reduce the risk of node lock-ups or timeouts.