ServiceNow PDI Reclamation Rules: Avoid Losing Access

Bill Martin · 3 weeks ago

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.

ralvarez

The 10-day login rule does not seem to be the whole story. I was actively logging in to my instance and lost it anyway.

That aside, good breakdown of the manual steps to back up your work on a PDI. I know them well, and even so I have lost work too many times. Running them by hand, again and again, is enough of a chore that sooner or later you put it off, and that is exactly when reclamation catches you. And sometimes there is no reclamation at all. A PDI can simply break, with no warning, no email, no countdown.

That is why I built a tool to automate the backup of a PDI. I put it on Share in case it helps others in the same situation: https://developer.servicenow.com/connect.do#!/share/contents/3108109_instance_backup

Bill Martin

Thanks for the feedback, @ralvarez, and for sharing that backup utility!

You are completely right that instances can occasionally encounter unexpected infrastructure issues or break without warning. I actually put this article together directly based on an official outreach communication from the ServiceNow Community Programs team outlining the strict rollout of the new lifecycle policies.

While ServiceNow explicitly mentions that the 10 day direct login rule and 90 day age limit are the specific triggers for automatic reclamation, your point underscores exactly why manual habits alone aren't enough. Having an automated way to handle backups on Share is a great resource for the community to safeguard their work against both automatic reclamation and unexpected system errors.

Thanks for contributing that!

ralvarez

Happy if it helps someone keep their work this week. Thanks for the kind words, Bill

rcastaldi

There seems to be a problem with the reclaim process. I use my PDI heavily, logged in directly many times last week including Friday, and yet it was reclaimed on Saturday.

Bill Martin

That is incredibly frustrating @rcastaldi , and it sounds like you hit a definite glitch in the automated rollout. If you were actively logging in directly as recently as Friday, you absolutely shouldn't have been caught by the 10 day inactivity trigger on Saturday.

In the meantime, if you need to stand up a new PDI, check out the automated backup utility that @ralvarez shared just above in this thread. It is a great resource to help protect your progress while the platform works out these early rollout bugs.

aashu002

Requested for new Instance 2 days ago still in waiting list.
anyone facing this same issue?

Nordrir

I'm literally logged into it right now, have been all day - was logged in yesterday, most of last week - and I just got a reclamation notice for Friday. Whatever the criteria is, it's VERY much not working.

Bill Martin

Hi @Nordrir,

That is incredibly frustrating. If you have been logged in directly all week, you absolutely should not be receiving a reclamation notice for this Friday. The inactivity criteria is clearly misfiring in your case.

Since you are actively logged in right now, you are doing exactly what is required to keep the instance alive based on the updated policy. It looks like the automated notification system is experiencing a major glitch and is out of sync with actual active sessions during this initial rollout phase.

Hopefully the system catches up and recognizes your activity before Friday. Keep us posted on whether the instance stays active!

Best,

Bill

Nordrir

So I think this is a different policy. The mail I'm getting is that it will be reclaimed, and that no extensions are possible. Whatever policy is driving this, has decided that I apparently can't retain my instance, regardless of use, and it can't be appealed nor extended.

I don't know where this comes from, there's no explanation, no background for it communicated in the email, but I know some of my colleagues have been informed similarly, despite actively developing applications on them, and testing solutions.

I guess we're going into potential forced rotation, where people are losing access entirely based on instance age, as SN no longer has the necessary capacity to run the required number of instances, and queuing is getting unmanageable.

hskchan

I agree with the other comments about inconsistent tagging of inactive PDI's. There is a bug (or some other criteria being applied) with the reclaim process. I just received a notice this morning that my PDI is to be reclaimed for inactivity. However, this morning when logging in to the Developer account to awaken the PDI I see the note that it has not been active for more than 8 days (and some minutes) even though I had been actively using it daily for the past few weeks including up to 6:30pm local time last night.

hskchan

Is there someone managing the PDI infrastructure we can contact with a problem with a reclaimed PDI? Specifically, I had a PDI that was reclaimed (no longer visible on my Developer's account) but it is clearly still running as the URL is valid (I just can't log in anymore as passwords have been reset). However, the problem is now someone/somehow, there are scheduled jobs activated on it and I am getting spammed with notifications from those jobs. To be clear, I never activated those jobs when I had the PDI and never had notifications before. All this happened AFTER the PDI was reclaimed.

Bill Martin

Thanks everyone for the detailed reports. A lot of what you're describing actually lines up with the recent infrastructure incident rather than the normal reclamation rules, so let me pull it together in one place.

For those of you getting reclamation notices while you were clearly still logged in and using the instance ( @Nordrir , @ralvarez , and whoever saw the "inactive 8 days" flag), those notices got caught up in the incident. If you received one during this window, treat that date as no longer valid. A new notice with an updated date should come before anything is actually reclaimed. So being flagged despite daily use isn't something you did wrong.

On the waiting list side @aashu002 , most instances came back online and provisioning picked back up, but a small number apparently stayed offline afterward. That's most likely why a fresh request is still sitting in the queue. It should clear as the rest recover.

@hskchan, yours is a different beast. An instance that's already off your account but still live and firing scheduled jobs you never set up, with no way to log in and stop them, isn't something the reclamation policy explains. That really does sound like a bug. I'd raise it on its own so it gets tracked as an infrastructure issue instead of getting buried in the general reclamation talk.

Hopefully that helps separate what's incident related from actual reclamation. I'll keep the thread posted as things settle down.