Unable to View Input Mapping Errors for HubSpot Destination

Feature request

Subject: Destination input-building errors are invisible in the UI

Hey team,

Flagging an observability gap we hit on a production destination — sharing in case it's useful.

What happened

Our HubSpot ContactCreateOrUpdateSignUp destination had a property mapping of {toUnixTimestampMilli(toDate(person.properties.trial_end_date))}. That expression is fine when the trigger event has trial_end_date populated on the person, but the destination fires on three sign-up events and only one of them (trial_sign_up_complete) actually sets that property. The other two produced toDate(null), which threw an error during input building.

Result over 7 days: ~136 HubSpot contacts silently missed. Success dropped 81% WoW while Failure sat at 0 the whole time, so it looked like an organic decline in sign-ups rather than a broken destination.

Where the errors show up (and don't)

• Metrics → Failure tile: 0. Input-building errors aren't counted here because the hog body never runs. Consistent with the tile's definition, but misleading in practice.
• Invocations tab: empty, even with "Logged errors" selected. Since input building happens before an invocation record is created, there's nothing for the tab to display.
• History tab: N/A — that's config-change history.

The only place these errors were visible was /api/projects/:id/hog_functions/:id/logs/, and only because we knew to look. A destination operator working from the UI would see nothing wrong.

Suggestions, in decreasing order of ambition

1. Track input-building errors as a first-class metric — a fourth tile alongside Success / Failure / Filtered (e.g. "Input errors") with a matching line on the volume chart. Highest-value change for us.
2. Write an invocation record for failed input-building attempts so they appear in the Invocations tab with a status like input_error. Would let operators filter, inspect, and re-run them from the UI.
3. At minimum, surface the raw log stream in the UI — either a dedicated Logs tab or folded into Invocations when no matching invocation row exists.

Happy to share destination id and error samples if it helps reproduce.

Thanks

Debug info

- [ ] PostHog Cloud, Debug information: [please copy/paste from https://us.posthog.com/settings/project-details#variables]
- [ ] PostHog Hobby self-hosted with `docker compose`, version/commit: [please provide]
- [ ] PostHog self-hosted with Kubernetes (deprecated, see [`Sunsetting Kubernetes support`](https://posthog.com/blog/sunsetting-helm-support-posthog)), version/commit: [please provide]

Start with the existing /api/projects/:id/hog_functions/:id/logs/ endpoint and trace how input-building errors are represented before the Metrics Failure tile and Invocations tab. Compare the three proposed surfaces, then define done as a chosen UI path that exposes these errors with an inspectable status or metric and verifies the relevant display behavior.