Duplicator Package Stuck at 'Building' or Showing Host Build Interrupt? Do This

If Duplicator's backup build is stuck at "Building," frozen at a specific percentage, or has stopped with a "Host Build Interrupt" message, the cause is almost always a server limit, not a bug in your Duplicator install. Duplicator's own guide treats Host Build Interrupt as a timeout imposed by the host (opens in a new tab) and lists the fixes: switch the SQL Mode, switch the archive engine to DupArchive, filter out large folders, and raise PHP limits. Start with the SQL Mode below — it's the lowest-risk change.

Symptoms

• The build progress bar stalls at the same stage every time (often during the "Scan" or "Files" step) and never reaches 100%.
• Duplicator shows an error referencing "Host Build Interrupt," a timeout, or an incomplete archive.
• The browser tab shows a blank white screen or a 500 error partway through the build.
• The build appears to complete, but the resulting archive is missing files or the installer.php file fails during a later migration attempt.

Likely causes, in order of how often they actually happen

1. The PHP execution time limit is too short for the site's size. Duplicator scans every file, packages the database, and zips everything within a single PHP process (or a series of them). On shared hosting with a default max_execution_time of 30–60 seconds, a build for a site with a large media library or many files will consistently hit this wall at roughly the same point.
2. The database export method isn't compatible with your host. Duplicator can generate the database export using the server's mysqldump binary or a pure PHP-based export. If mysqldump isn't available, isn't in the expected path, or your host's shell access restrictions block it, the build fails during the database stage specifically — this is a very common host-specific issue on locked-down shared hosting.
3. The ZipArchive engine can't run or can't finish. Duplicator's default archive engine uses PHP's ZipArchive extension; if it's missing, or the zip step runs longer than the host allows, the build stalls at the archive stage. Duplicator's own DupArchive format (opens in a new tab) exists for exactly this (limited to 500 MB backups in Duplicator Lite).
4. The site is simply too large for the host's resource ceiling in one pass, compounding whichever of the above is already marginal — very large media libraries or file counts (tens of thousands of files) push past what the host allows regardless of individual settings.

Fix it: lowest-risk steps first

Step 1 — Switch the database export mode

This is a setting change inside Duplicator itself, with no server configuration required, so try it first.

1. Go to Duplicator → Settings → Backups (called Packages in older versions).
2. Find SQL Mode (Duplicator's guide (opens in a new tab)).
3. Switch between Mysqldump and PHP Code — whichever it isn't currently using. The two methods have different compatibility profiles depending on host configuration, so switching often resolves a build that consistently fails at the database step.
4. Start a new build and watch whether it gets past the point where it previously stalled.

Step 2 — Switch the archive engine to DupArchive, or enable ZipArchive

1. In the same Settings → Backups screen, set Archive Engine to DupArchive; Duplicator says it greatly reduces the chance of a build timeout (opens in a new tab), with a 500 MB backup limit in Duplicator Lite. If you'd rather keep ZipArchive, Duplicator's pre-build scan flags the extension when it's missing.
2. If it's shown as missing or disabled, contact your hosting provider's support and ask them directly whether the php-zip (or zip) extension is enabled for your PHP version — on many hosts this is a quick one-line change on their end, or something you can toggle yourself if you have access to select PHP extensions in a control panel like cPanel's "Select PHP Version" tool or aaPanel's PHP extension manager.
3. Retry the build.

Step 3 — Raise PHP execution time and memory limits

If the build is stalling on file scanning or archiving rather than the database step, this points to a resource ceiling rather than a compatibility issue.

1. If you have access to wp-config.php, add define('WP_MEMORY_LIMIT', '512M'); above the "That's all, stop editing!" line.
2. If your host provides a PHP configuration editor (cPanel's MultiPHP INI Editor, aaPanel's PHP settings, or similar), raise max_execution_time to 300 or higher and memory_limit to 512M.
3. If you don't have panel-level access, ask your host to temporarily raise these limits for the account — this is a routine, low-risk request most hosts will fulfill quickly, and you can ask them to revert it afterward if you'd rather not leave it raised permanently.
4. Retry the build after the change takes effect (some hosts require a few minutes, or a PHP process restart, for new limits to apply).

Step 4 — Reduce what the package needs to process

If the build still won't complete after Steps 1–3, the site's raw size relative to your host's ceiling may be the underlying issue.

1. When creating the backup, use Duplicator's file and folder filters to exclude large, non-essential directories — cache folders, old backup zips in wp-content, or unused media. Duplicator's guide notes that filters on a large folder like wp-content/uploads (opens in a new tab) are often enough to get a build to finish.
2. Rebuild after excluding these — a smaller file count and package size often succeeds where the full-site build was hitting a wall, and you can copy any excluded files over separately via FTP if needed.

Verify the fix

1. The build reaches 100% and Duplicator generates both the archive file and the installer.php file without an error banner.
2. Download both files and confirm their file sizes look reasonable (not suspiciously small, which can indicate a truncated build).
3. If you're using the package immediately for a migration, run the installer on the destination and confirm it completes through the database and file-extraction steps without repeating the same error.

If you need to roll back

Building a package doesn't alter your live site's files or database, so there's nothing to roll back on the source site itself. If you changed PHP settings in wp-config.php or a hosting panel and want to revert them once the build succeeds, simply restore the original values you noted in the backup warning above. If a partial or corrupted archive was generated, just delete it from Duplicator → Packages and start a fresh build rather than trying to reuse it.

Related fixes

• The Best WordPress Backup Plugins (And Common Fixes) — For a full comparison of backup and migration plugins, and what actually determines whether a restore will work.
• WPvivid Restore Stuck or Failed — For a similar stuck-process issue during a restore rather than a migration build.
• All-in-One WP Migration Didn't Replace All Your URLs — For a different migration-plugin issue affecting URLs after import.

FAQ

Which database export mode should I use by default, mysqldump or PHP-based?

Neither is universally better — it depends entirely on what your specific host supports and how it's configured. mysqldump is typically faster for large databases when it's available and correctly permissioned, while the PHP-based method is more portable across restrictive hosting environments that block shell access. If one mode fails, trying the other is a legitimate diagnostic step, not just a workaround.

Does a Host Build Interrupt mean my hosting plan is too small for WordPress?

Not necessarily. It usually just means the specific PHP resource limits your host applies by default (execution time, memory) are lower than what a full-site archive-and-database export needs in a single pass — this is common even on otherwise perfectly adequate hosting plans, and is fixable via the steps above rather than requiring an upgrade.

Can I build the package in smaller batches instead of all at once?

Duplicator doesn't offer manual batching of a single package build, but excluding large non-essential folders (Step 4) effectively achieves the same result by reducing what needs to be processed in one pass. For very large sites, some users build core files and media as separate migrations rather than one combined package.