Your ServiceNow Personal Developer Instance can be reclaimed if it is old enough and you have not logged in directly within the required time. Since July 11, 2026, ServiceNow has begun applying its updated PDI reclamation policy to inactive instances.
If you use a PDI for practice, testing, or building applications, check its status and protect any work you want to keep. The policy depends on more than whether you have visited the ServiceNow developer website.
ServiceNow Began Reclaiming Inactive PDIs on July 11
ServiceNow's updated PDI reclamation policy took effect on July 11, 2026. A Personal Developer Instance is a useful place to learn the platform, test scripts, configure applications, and try ideas without working in a production environment. However, it is not intended to act as permanent storage for months or years of work.
The policy addresses two problems that have affected the developer community: a large waitlist for instances and limited capacity. When inactive PDIs stay assigned to accounts indefinitely, other people may wait longer to get an environment for hands-on learning and development.
Effective July 11, 2026, ServiceNow can automatically reclaim a PDI that meets both inactivity conditions.
If you recently signed in and found that your environment looks different, is unavailable, or no longer contains your previous work, reclamation may be the reason. You should first check your ServiceNow notifications and email history for messages tied to your instance.
This change does not mean you should stop using a PDI for serious learning. It means you need to treat it as a temporary environment and keep important work somewhere outside the instance. Your configurations, update sets, custom records, scripts, and property values can take many hours to build. Those hours are much easier to preserve when you export work regularly instead of waiting until an instance becomes unavailable.
The policy also creates a simple maintenance habit: log in directly to the PDI on a regular schedule. That direct login matters because ServiceNow does not count every kind of account activity toward keeping the instance active.
The Two Conditions That Trigger PDI Reclamation
ServiceNow reclaims a PDI only when it meets both conditions in the policy. An instance must be at least 90 days old, and you must not have completed an explicit login to that particular PDI within the previous 10 days.
The requirements are easiest to compare side by side:
| Reclamation condition |
What it means |
| Instance age |
Your PDI has been provisioned for 90 days or more |
| Login inactivity |
You have not explicitly logged in to that PDI during the last 10 days |
An instance that is only a few weeks old does not meet the age condition. Likewise, an older instance remains outside the stated trigger if you have logged in directly to it within the 10-day period. Both conditions must apply before automatic reclamation occurs.
The distinction around login activity is important. Visiting the main ServiceNow developer site does not count as an explicit login to your PDI. Background processes also do not count. A scheduled job, an integration, or other activity inside the environment cannot replace a direct user login.
You need to access the actual developer instance itself. In practical terms, that means opening your PDI and signing in to that environment, rather than only managing your account through the developer portal.
This is easy to overlook if you work across several instances. You might visit the developer site often, request an instance, check community resources, or review account details, yet still fail to log in to the PDI that holds your work. If that instance is more than 90 days old, the 10-day clock still applies.
Set a recurring reminder that matches how you use your instance. For example, if you build in your PDI only on weekends, make direct PDI access part of that routine. A brief login can prevent an avoidable disruption, but it should not replace backups.
Check the ServiceNow Warning Emails
ServiceNow sent reclamation-related notifications in stages before the policy took effect. If you believe an instance may have been affected, search your inbox for ServiceNow messages around the rollout dates.
The notification schedule included the following dates:
| Date |
Notification |
| July 7, 2026 |
Initial alert |
| July 10, 2026 |
Final 24-hour reminder |
| July 11, 2026 |
Final reclamation notice |
These messages can help you determine whether your PDI was identified for reclamation. Search for emails from ServiceNow, then review the message dates and any instance details included in the notifications.
If you do not see the notices in your inbox, check your spam, junk, and filtered folders before assuming ServiceNow did not contact you.
Email warnings are useful, but they should not be your only safeguard. Inbox rules can archive messages, a notification can land in junk mail, and you may not notice an alert during a busy week. Your own backup routine gives you more control than an email reminder received at the last minute.
If you have more than one environment associated with your account, review each one rather than assuming activity in one PDI protects another. The policy focuses on a direct login to the particular instance at risk. Keep track of which PDI contains active learning projects or application work, then access that environment regularly.
Back Up Your Work Outside the PDI
A PDI is built for learning and short-term experimentation. You should never treat it as the only location for work you want to retain. Reclamation can remove access to an inactive instance, and an external backup gives you a path back to your configurations and custom development.
Start by exporting your current update sets to local storage. Update sets can capture many configuration changes, and an exported copy gives you a record outside the instance. Review the work you have in progress before exporting, especially if you have multiple update sets or changes that are not yet organized.
Next, connect scoped applications to source control. A Git repository gives you a separate history of application files and changes. This is particularly useful for application development because you can preserve work outside the PDI rather than relying on one temporary environment.
Finally, perform regular XML exports for custom data, scripts, and system properties. Update sets do not remove the need to think about the other pieces of your work. If you created custom records, stored values in system properties, or built scripts that need separate preservation, export them as part of a planned backup routine.
Use these three actions as the foundation of your protection process:
- Export current update sets to local storage.
- Connect scoped applications to a Git source-control repository.
- Export custom data, scripts, and system properties as XML on a regular basis.
Keep your exported files somewhere you can find later. A local copy that is buried in an unknown downloads folder can become almost as hard to use as a missing instance. Give backups clear names, retain them in an organized location, and update them when your work changes.
You should also avoid waiting for an inactivity warning before exporting. Backups work best as a normal part of development, such as after completing a feature, before a major configuration change, or at the end of a practice session. That habit protects your work even if you later forget to log in within the required 10-day window.
A More Available PDI Platform for Active Developers
The new policy requires an adjustment, particularly if you used to leave a PDI untouched for long periods. Still, its stated purpose is practical: ServiceNow can free capacity from inactive environments and make developer instances more available to people who are actively building on the platform.
The long-term goal is a more stable, performant, and available ServiceNow developer infrastructure for active users.
You do not need to use a PDI every day. However, once it reaches 90 days old, you need to log in directly at least once within each 10-day period if you want to keep it active under this policy. Treat that login as routine maintenance, similar to checking the status of an environment before starting work.
External backups remain the stronger protection. A direct login may preserve access, but it does not protect you from every situation where you might need to rebuild or restore your work. Exported update sets, source control, and XML exports give you copies that do not depend on the continued availability of a single PDI.
If this policy changes how you organize learning projects or development work, build the new timing into your workflow now. A small recurring habit can save you from having to recreate configuration work later.
Keep Your PDI Active and Your Work Portable
The policy comes down to one operational rule: if your PDI is at least 90 days old, log in directly to that specific instance at least once every 10 days. Visiting the developer portal or relying on background activity does not meet that requirement.
Your best defense is a combination of regular PDI access and external backups. Export your work before you need it, keep important application code in source control, and avoid leaving valuable configurations in only one temporary developer instance.
