Logs & Observability

Every Proxy, Unified API and MCP request is logged. When a customer reports “the sync stopped working”, the logs show what BundleUp sent to the provider and what came back.

​

Viewing logs

Open Logs in the dashboard. You’ll see a chart of successful and failed requests over time, and a table of individual requests. Filter by:

• Status code, for example only 4xx or a specific 429.
• Integration, to focus on one provider.
• Time range.

​

What each entry contains

Bodies and headers are never logged.

​

Error codes in logs

A request that was retried shows up as several entries: one integration_request_retry per failed attempt, then the final result.

​

Retention

Entries older than that are deleted automatically.

​

Debugging with logs

A user says an integration stopped working. Filter by the integration and look for that user’s connection. A run of 401s from the provider usually means they revoked access; connection_refresh_failed means the refresh token no longer works. Either way, ask them to reconnect. Requests are slow. Sort by duration. Long durations with integration_request_retry entries mean the provider was failing and BundleUp was retrying. Long durations without retries mean the provider itself is slow. You’re hitting 429s. Check whether the entries show rate_limit_exceeded (BundleUp’s per-connection limit) or a provider 429 (the provider’s limit). See Rate limits.

​

Logging on your side

BundleUp’s logs cover what happened between BundleUp and the provider. Keep your own logs of which user and feature triggered each call, and include the connection ID so you can match entries across both.