# Debug bundles When a failure does not make sense, the run log often is not enough: it says what happened, not what the page looked like. A debug bundle is the export that answers the second question. It contains full page content, so treat it as page content when you decide where to send it. --- ## What is in a bundle * Each page's full content, in two formats. * Attachment and content listings for those pages. * The run's own record for the same pages. Attachment and diagram file contents are not included, so a bundle is much smaller than an export of the pages themselves. --- ## How to build one | **From** | **Gets you** | | --------------------------------- | ------------------------------------------- | | A single page in the activity log | That one page | | An unrecognised error group | Every page behind that group, up to the cap | ⚠️ **Bundles include page bodies in full.** The product says so before it builds one. Check what is on those pages before attaching a bundle to a ticket, and prefer a single-page bundle where it will do. --- ## Limits * Capped at 25 pages, sampling the rest if the group is larger. * Only one bundle can be built at a time. * Bundles are built from the results on screen, so the same rule applies: build it before you navigate away. --- ## A few things that catch people out * A single-page bundle is usually enough to diagnose a failure class. Start there. * The 25-page cap applies however many pages hit the same problem, so a bundle is a sample rather than a census. * If a failure group carries a hint, follow the hint first. Bundles are for the unrecognised ones. --- ## Related [Downloading the run logThe lighter export.](https://help.gocapable.com/migration/downloading-the-run-log.html) [TroubleshootingBefore you raise a ticket.](https://help.gocapable.com/migration/troubleshooting.html) [Reading the resultsFinding the group to bundle.](https://help.gocapable.com/migration/reading-the-results.html) --- _Full page content. Send it carefully._