How Often Can You Refresh a Salesforce Sandbox? Limits by Type

Salesforce limits how often each sandbox type can be refreshed: Developer and Developer Pro sandboxes once per day, Partial Copy sandboxes every 5 days, and Full sandboxes every 29 days. You can't refresh more often than that. What you can do is keep data fresh between refreshes by loading or replicating records into the sandbox you already have.

That second part is where most teams actually get stuck. The interval is rarely the real problem. The problem is that a refresh is a heavy operation that wipes whatever you built in the sandbox, so even when you're allowed to refresh, you often don't want to.

What are the refresh intervals for each sandbox type?

The refresh interval is fixed per sandbox type, and it scales with how much data the sandbox copies. Salesforce documents these intervals in Refresh Your Sandbox and its sandbox types and best practices article:

The pattern is simple: the more production data a sandbox holds, the longer you wait between refreshes. Developer sandboxes are cheap to rebuild because there's no data to copy. Full sandboxes copy everything, so Salesforce throttles them hardest.

What actually happens when you refresh a sandbox?

A refresh replaces the sandbox with a new copy of the source org's metadata and, for Partial Copy and Full sandboxes, its data. Everything that existed only in the sandbox is lost. A few side effects are worth knowing before you click the button:

• The org ID changes. Salesforce states that "the org ID of the sandbox changes each time it's refreshed." Anything keyed on the old org ID — license checks, integration configs, allowlists — needs updating.
• Sandbox-only work disappears. Test records, half-finished configuration, and users you created only in the sandbox are gone once you activate the new copy. Deploy or back up anything you want to keep first.
• It's irreversible once started. You can activate or discard the refreshed copy, but you can't cancel back to the old one. A discarded copy can't be recovered.
• Timing is unpredictable. Salesforce says sandboxes "aren't guaranteed to complete by a certain time". Copy time depends on data volume, customization, and demand, and it gets slower around major releases.
• Some things don't come across. Scheduled Apex jobs from the source org aren't copied and must be rescheduled, and Salesforce-to-Salesforce connections have to be reactivated (considerations).
• Email is locked down by default. User email addresses get .invalid appended, and new and refreshed sandboxes default to the "System email only" deliverability setting.

That last group turns every refresh into a small project. We cover the full cleanup in the post-refresh checklist later in this series.

Why does the refresh interval matter so much?

The interval matters because production keeps moving while your sandbox stands still. With a Full sandbox, a UAT cycle that starts on day 20 of the window is testing against data three weeks old, and the next refresh is still more than a week away. Bugs that depend on recent records — last month's new product, a pricing change, an integration that started writing a new field — don't reproduce.

There's also a coordination cost. Because a refresh wipes the sandbox, one team's refresh is another team's lost work. Teams often end up refreshing less often than allowed, which makes the data even staler.

How do you keep sandbox data fresh between refreshes?

You keep data fresh between refreshes by moving records into the existing sandbox instead of rebuilding it. The refresh interval limits how often Salesforce re-provisions the org. It doesn't limit how often you insert, update, or delete records through the API. Your options:

1. Use a lighter sandbox type. If you don't need all of production, a Partial Copy sandbox refreshes every 5 days, and a sandbox template controls which objects come across. The trade-off is limited per-object control and a 5 GB ceiling. See our sandbox alternatives roundup for more on this.
2. Targeted data loads. Export a slice of production with Data Loader or the Salesforce CLI and upsert it into the sandbox using external IDs. This works well for a few objects. It gets painful when you have to handle load order, lookups, and PII masking yourself across dozens of objects.
3. Synthetic data. For development and QA that doesn't need real records, generated test data avoids the refresh question entirely. You can reseed as often as you like, and there's no PII to worry about.
4. API-based replication into an existing sandbox. A replication tool reads from production and writes into the sandbox you already own, keeping relationships intact. Run it before a test cycle, after a big production data load, or whenever the data drifts. Incremental (delta) runs move only what changed since the last run, so each refresh costs minutes, not a re-provisioning cycle.

A common setup combines these: Developer sandboxes with synthetic data for day-to-day work, plus one longer-lived sandbox that's kept current by incremental replication for integration testing and UAT.

Where does Syntharil fit?

Syntharil's sandbox replication is one option for the fourth approach. It copies the objects you choose from production into any org you already own, on demand, with a SOQL filter per object. It remaps lookups and polymorphic references, inserts in dependency order, and masks PII deterministically while the records are in transit. With the Hybrid strategy, the first run is a full copy and later runs pick up only records created, changed, or deleted since the last run. Runs start from the UI, the API, or the CLI, so you can trigger them from a CI script. It doesn't copy Chatter, User records, or field history, so it complements platform refreshes rather than replacing a Full sandbox in every case.

Bottom line

You can't refresh a Salesforce sandbox more often than its type allows: daily for Developer and Developer Pro, every 5 days for Partial Copy, every 29 days for Full. Because a refresh wipes sandbox-only work, most teams should refresh deliberately and handle day-to-day freshness another way. Use synthetic data where you don't need real records, and targeted loads or incremental replication into an existing sandbox where you do.