If Duplicator's package build is stuck at "Building," frozen at a specific percentage, or has stopped with a "Host Build Interrupt" style message, the cause is almost always one of three server-side limitations, not a bug in your Duplicator install: a PHP execution time limit that's too short for the site's size, the ZipArchive PHP extension missing or disabled on your host, or a database export method that your host doesn't fully support. Start with the database export setting below — it's the lowest-risk change and fixes the most common case.

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 PHP extension isn't enabled. Duplicator needs ZipArchive (or a compatible fallback) to compress the package. If it's disabled at the server level, the build can stall or fail during the compression stage without an obviously descriptive error.
  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 → Packages → Create New.
  2. On the build screen, look under the Archive or Database settings section for the database export/build mode option (Duplicator exposes this as part of its package build settings).
  3. If it's currently set to use mysqldump, switch it to the PHP-based export method, or vice versa — 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 — Confirm ZipArchive is enabled with your host

  1. Check your site's PHP configuration — Duplicator's own pre-build scan (on the Setup step, under "System" or a similar diagnostics section) typically flags missing extensions including ZipArchive.
  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. Once confirmed enabled, 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. On the Setup step of package creation, use Duplicator's file/folder exclusion options to exclude large, non-essential directories — cache folders, old backup zips sitting in wp-content, or unused media that doesn't need to migrate.
  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

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.