Persistent HubSpot Projects WEBHOOKS backend deploy failure across two projects

Developer Support APIs & Integrations
1

Hi HubSpot Developer Support,

We are seeing a persistent server-side deployment failure in HubSpot Projects across two independent apps in the same developer account. Both source-complete builds validate locally, and every component except the WEBHOOKS component deploys successfully.

Latest failures

  • Project A: build #15, deploy #22; correlation ID 019f6e12-e62d-71c5-8d43-d3229f72eb0e. The deployed build remains #11.
  • Project B: build #14, deploy #23; correlation ID 019f6e13-1b6a-7419-9877-cc6b840feed4. The deployed build remains #12.

Exact CLI error

A backend service was temporarily unavailable while deploying WEBHOOKS kiingo_crm_object_webhooks. This is usually transient — please re-run your deploy. If it persists, contact support with correlation-id: …

What we have confirmed

  • App metadata deploys successfully.
  • The workflow action kiingo_record_workflow_execution deploys successfully.
  • Only WEBHOOKS kiingo_crm_object_webhooks fails.
  • Multiple retries separated by cooldown periods continue to fail on both projects.
  • Our remote verifier confirms there was no partial webhook activation.
  • The public HubSpot status page reports Developer Tools and APIs operational.

Previous correlation IDs showing the same persistent failure include:

  • 019f6d4c-743d-776c-a827-c4c9fcf2dd71
  • 019f6d4c-e55c-7b43-b13e-f763b26bf993
  • 019f6d15-3e69-7b20-af8d-c53a1688a41b
  • 019f6d15-86b5-7364-b210-6a748630f7d3

Could the HubSpot Projects/Webhooks engineering team inspect these correlation IDs, repair or reset any stuck backend component state, and confirm when the source-complete builds should be safe to deploy? I can provide developer-account, project, and app IDs privately; I have omitted them here because this forum is public.

Thank you.

4

Hi @rosshartmann and welcome, we are delighted to have you on the HubSpot Community!

Thank you for detailing your deployment experience and sharing the correlation IDs.

I can see that you also contacted our Support team for this, you can always re-open the ticket at anytime, since Support is the best next step here.

In the meantime, let me flag this for our Developer team’s visibility. Could you please share this additional information for the investigation:

  • Total subscription count per app: if either app has >200 subscriptions being created/updated/deleted in a single deploy?

  • Whether the targetUrl changed between the last successful deploy and the failing builds?

  • Whether a previous deploy partially succeeded before the failures started?

Thanks and I’ll get back to you as soon as possible.

Bérangère

This post was created with the assistance of AI tools

7

Hey @rosshartmann, I hope that you are well!

Just wanted to check in on you, do you still need help?

If yes, can you please share the information listed in my first reply?

Thanks and have a lovely day!
Bérangère

8

Hi @rosshartmann, since only WEBHOOKS fails across two projects, I would package this as a stuck component-state escalation rather than more retries.

Useful bundle for Support/DevTools:

  • @hubspot/cli version. Current latest is 8.10.0.
  • Node version.
  • Last successful build/deploy IDs for each project.
  • Full failing deploy IDs plus correlation IDs.
  • Whether subscription count is over 200, targetUrl changed, or a previous webhook deploy partially succeeded.
  • A minimal deploy where only one subscription is changed or removed.
  • A screenshot/log showing the deployed build remains #11/#12 after the failed deploy.

I would not keep retrying source-complete deploys until HubSpot confirms the component state is clear. If a minimal webhook-only change also fails with a fresh correlation ID, that is strong evidence for backend state rather than project source.