Your HubSpot workflows are keeping scary secrets from you.

Everything in your workflow action log may appear green, so it’s easy to assume your automation is fine. But the truth is HubSpot Custom Code Actions can fail silently.

An action may be marked with “Success” but the reality is that you might not find out the truth until month-end when Sales ask why the lead handover numbers don’t match the marketing campaign reports.

So what’s going wrong in your workflow? Well, potentially anything…

An API call might time out. A payload might be malformed. The downstream system might reject the request. The input might be the wrong data type. Your code might not handle missing data correctly.

But HubSpot will still record Success because the container finished running the code without crashing.

That’s the heart of the observability gap: HubSpot tells you the code executed, not that it did what you wanted.

🧠 Execution success ≠ Business success

I’l give you an example. Imagine a workflow that imports delegates registering in an external Event Management tool.
A webhook triggers the workflow, and a Custom Code Action (CCA) calls your event system’s API to retrieve the data, and then you write this to HubSpot.
If the API key has expired, or you exceed rate limits, a 4XX error will be received from the API – but the code still runs to completion.
You could write this error to an output on the variable, but you can only access the data in this during testing. It won’t appear in the action logs once it is running. When your script is done it exits normally and the workflow moves to the next action.

HubSpot shows “success” for that action in the action logs, but:

• No registrant was imported.
• No record was created.
• No error email.
• No visual clue in the workflow history.

From HubSpot’s point of view, the function ran to completion.
From your business’s point of view, it failed.

⚙️ Why this happens

HubSpot’s workflow engine cares only about execution status:

What HubSpot sees	What actually happened
Script completed without throwing an unhandled exception	Any mix of success, partial success, or silent failure

Unless you explicitly code to throw a code execution error, HubSpot reports “Succeeded.”

🔎 Why observability matters

Automation is crucial for scaling growth and HubSpot workflows are immensely powerful. But the nature of automation is to mask activity. No one is watching each action: it happens out of sight. ‘Observability’ attempts to remedy this.

Without real observability you can’t:

1. Receive real time alerts when errors and issues occur.
2. Diagnose logic errors based on information captured when the workflow is running. e.g. was a contact skipped because of missing data, or an API limit?
3. Measure reliability: You can’t tell if that 99 % “Success” rate is genuine or masking silent skips.
4. Control cost: Endless retries or hidden loops chew through API quotas.
5. Provide auditability: Compliance teams need evidence that automations ran correctly.

In short, you can’t improve what you can’t see.

🧰 What you can do about it: external logging

With HubSpot workflows you have three options for visibility:

1. The workflow action history.
2. Catching error_states from your code and using branching logic to trigger in-app or email notifications on failure.
3. Your own logging layer inside your workflows.

Option 1 will miss errors and it won’t provide the insight you need to debug and make improvements. If you choose this option, you may only find out about a critical problem well after it happened..

Option 2 brings more visibility to issues, but doesn’t create searchable data. When a high number of errors occurs you can quickly become swamped.

Option 3 provides a powerful tool to log not just every error and drive alerting, but every successful action can be logged too. Connect your logs to a Looker dashboard and you have a powerful tool to monitor key processes.

Why it fits so well:

• Free tier: 50 GiB/month ingestion, 30-day retention.
• Structured data: search logs by workflow name, contact ID, severity or even a particular workflow branch or action.
• No extra services: A single REST API endpoint you call with an access token.

With just a few lines of code, every custom code action can stream detailed, structured logs to Cloud Logging and covering both technical and business outcomes:

{
  "process": "EventRegistrantSync",
  "severity": "ERROR",
  "labels": { "rate_limited": "true" },
  "jsonPayload": {
    "hs_contact_id": "12345",
    "event_id": "67879",
    "error_message": "Error 429: API rate limit exceeded."
  }
}

Now, even if HubSpot shows Success, you’ll see the truth in your logs.

🪜 What you’ll learn next

This article introduced the why.
In the next parts we’ll cover the how:

1. Part 2: Setting up Google Cloud Logging
   Create a project, enable the API, and stay within the free tier (your organisation may have an existing platform that accepts logs via HTTP/REST api).
2. Part 3: Securely connecting HubSpot to Google Cloud
   Split and store your service-account key as multiple HubSpot secrets.
3. Part 4: Best practices for structured logging
   Using labels, severity, and masking to make logs useful and privacy-safe.

---

💬 Takeaway

HubSpot’s Workflow Metrics and Action Logs can only indicate which branch was taken or that your code ran.

• It doesn’t mean your automation worked.
• It won’t help you identify or debug the different failure modes in your process.

Until you give your workflows proper observability (external, structured, searchable): you’re flying blind.

Cloud Logging closes that gap.

In Part 2, we’ll configure Google Cloud Logging in less than ten minutes.