> ## Documentation Index
> Fetch the complete documentation index at: https://bundleup.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Logs & Observability

> See every request made through BundleUp: what was called, how it went, and how long it took.

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

| Field | Description |
| - | - |
| Time | When the request was made. |
| Source | `PROXY`, `UNIFY` or `MCP`. |
| Method and URL | The provider URL BundleUp called. For requests rejected before reaching the provider, the BundleUp URL you called. |
| Status | The final status code returned to you. |
| Duration | Total time in BundleUp, including retries and waiting on the provider. |
| Connection | The connection used. |
| Integration | The connection’s integration. |
| API key | Which of your keys made the request. |
| Error code | Set when the request failed. See below. |

**Bodies and headers are never logged.**

### Error codes in logs

| Code | Meaning |
| - | - |
| `connection_invalid` | The connection ID was missing, unknown or from another workspace. |
| `rate_limit_exceeded` | The connection was over its rate limit. Nothing was sent to the provider. |
| `connection_refresh_failed` | The token had expired and couldn’t be refreshed. |
| `connection_invalid_after_refresh` | Unified API: as above. |
| `integration_not_found` | The connection’s integration no longer exists. |
| `integration_method_missing`, `integration_method_invalid` | Unified API: the provider doesn’t support that endpoint. |
| `mcp_not_supported` | MCP: the provider has no MCP server. |
| `integration_request_retry` | An attempt failed and was retried. One entry per failed attempt. |
| `integration_request_failed` | The provider returned a non-2xx response on the final attempt. |

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

## Retention

| Plan | Logs kept for |
| - | - |
| Free | 1 day |
| Pro | 14 days |

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 `401`s from the provider usually means they revoked access; `connection_refresh_failed` means the refresh token no longer works. Either way, ask them to [reconnect](/docs/guides/auth/connection-lifecycle#when-a-refresh-fails).

**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 `429`s.**
Check whether the entries show `rate_limit_exceeded` (BundleUp’s per-connection limit) or a provider `429` (the provider’s limit). See [Rate limits](/docs/guides/proxy/rate-limits#bundleups-limit-vs-the-providers).

## 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.