Retrying Failed Tasks

When an import, deployment, or bulk operation fails or partially completes, you can retry it directly from the Activity Log. Retrying resubmits the failed assets for processing without requiring you to reconfigure the entire operation from scratch.

When to Retry

Retry is available for tasks with a Failed or Partial status. The most common scenarios where retrying resolves the issue:

• Transient API errors — HubSpot’s API occasionally returns temporary errors (rate limits, timeouts, 5xx errors). Retrying after a short wait usually succeeds.
• OAuth token expired mid-task — If the portal connection dropped during processing, reconnect the portal first (see Reconnecting a Portal), then retry.
• Rate limit exhaustion — Large operations can hit HubSpot’s API rate limits. JetStack AI includes automatic retry logic with rate limit header awareness, but in extreme cases the retries may be exhausted. Waiting a few minutes and retrying the task manually resolves this.
• Dependency ordering issues — If a deployment partially failed because some dependencies were not yet created, retrying after deploying the dependencies often succeeds.

How to Retry

1. Navigate to the Activity Log in the left sidebar.
2. Find the failed or partial task. Use filters to narrow results if needed (filter by Failed or Partial status).
3. Click Retry in the Actions column, or open the Task Details page and click Retry from there.
4. A new task is created and immediately starts processing.

The retry action creates a new task in the Activity Log. The original task remains in the log with its original status for your records. This means you can compare the original failure with the retry results.

What Gets Reprocessed

The scope of a retry depends on the original task’s status:

Retrying a Failed Task

When you retry a task that fully Failed, all assets in the original task are resubmitted for processing. The retry behaves identically to running the original operation again.

Retrying a Partial Task

When you retry a task with Partial status, only the failed assets are resubmitted. Assets that succeeded in the original run are not reprocessed. This prevents duplicate creation and saves time.

For example, if an import of 30 assets completed with 25 succeeded and 5 failed, retrying resubmits only the 5 failed assets. The 25 that already succeeded are left untouched.

Skipped Assets

Assets that were skipped (due to duplicate detection or circular dependencies) are not included in retries. Skipping is considered an intentional outcome, not an error. If you want to force-process a skipped asset, you need to start a new operation.

Before You Retry

Before clicking Retry, check whether the underlying cause has been resolved. Retrying without addressing the root cause will produce the same failures:

• Authentication errors — Verify the portal shows a green Connected status in Client Accounts. If it shows yellow or red, reconnect first.
• Missing dependencies — If deploy errors reference missing properties, pipelines, or custom objects, deploy those dependencies first, then retry the main task.
• Rate limits — Wait at least 2-3 minutes after a rate limit failure before retrying. HubSpot’s rate limit window resets on a rolling basis.
• Configuration errors — If assets failed due to invalid configurations (unsupported field types, missing required values), these will not resolve on retry. You may need to re-import the source assets or fix them in HubSpot before retrying.

Retry Limits

There is no hard limit on how many times you can retry a task. Each retry creates a new task entry, so your Activity Log will show the full history of attempts. However, repeatedly retrying a task that fails for the same reason is not productive — investigate the Task Details to understand the error before retrying.

Cancelling a Retry

If you start a retry and realize you need to stop it (e.g., you forgot to reconnect the portal first), you can cancel the in-progress retry task the same way you cancel any in-progress task — click Cancel in the Activity Log or from the task detail page.

Retry vs. Starting Over

In some cases, retrying is not the right approach. Consider starting a fresh operation instead when:

• The original task had fundamentally wrong configuration (wrong source portal, wrong asset selection).
• You need to include additional assets that were not in the original task.
• The asset data in the source portal has changed significantly since the original task.

To start a fresh operation, go back to the relevant feature (Import, Deploy, or Bulk Properties) and configure a new task from scratch.