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

# Logs export

> Stream your MCP server's logs to your own observability backend over OTLP.

Alpic can push every log line your MCP server writes to any OpenTelemetry-compatible backend over OTLP/HTTP: Datadog, Grafana Cloud, Honeycomb, New Relic, or your own collector. There is nothing to install and no change to your code or deploys. Configure a destination once and lines start arriving within seconds.

<Note>
  Logs export is available on **paid plans**. Destinations are configured per environment, so staging and production can
  point at different backends.
</Note>

## Set up a destination

<Steps>
  <Step title="Open the Telemetry settings">
    In your project **Settings**, open the **Telemetry** section and pick the environment to configure.
  </Step>

  <Step title="Enter the destination endpoint">
    Paste the **full** logs URL from your vendor, signal path included, for example `https://otlp.example.com/v1/logs`.

    We push to this URL exactly as you enter it and **never append a path**. If your vendor documents a base URL like `https://otlp.example.com` and a signal path like `/v1/logs`, enter the two joined together. `/v1/logs` is only the OTLP default: some vendors serve a different path, or a different host per signal, so always copy the URL your vendor documents for logs.

    You can add more than one destination with **Add destination**, and the same logs go to all of them. Each destination is configured, tested and stopped on its own.
  </Step>

  <Step title="Pick the protocol">
    `HTTP/protobuf` is the OTLP default. Switch to `HTTP/JSON` only if your backend asks for it.
  </Step>

  <Step title="Add the authentication header">
    Authentication is a header you copy from your vendor, such as `Authorization` or `DD-API-KEY`, with your API key as
    the value. Mark it **secret** so it is stored write-only and never shown again.
  </Step>

  <Step title="Save and send a test log">
    Save the destination, then click **Send a test log**. Alpic pushes one synthetic log record through the exact same path your real logs take and shows you the backend's answer.
  </Step>
</Steps>

## Common vendors

Always copy the endpoint from your vendor's OTLP documentation, since regions and paths vary by account. Typical shapes:

| Vendor        | Logs endpoint shape                                      | Authentication header                          |
| ------------- | -------------------------------------------------------- | ---------------------------------------------- |
| Datadog       | see Datadog's OTLP intake docs for your site             | `DD-API-KEY: <API key>`                        |
| Grafana Cloud | `https://otlp-gateway-<region>.grafana.net/otlp/v1/logs` | `Authorization: Basic <base64 instance:token>` |
| Honeycomb     | `https://api.honeycomb.io/v1/logs`                       | `x-honeycomb-team: <API key>`                  |
| New Relic     | `https://otlp.nr-data.net/v1/logs` (EU: `otlp.eu01.…`)   | `api-key: <license key>`                       |

## Verify the destination

**Send a test log** reports exactly what your backend answered:

* **The destination answered**: the record was accepted end to end, so real logs will flow.
* **Credentials rejected**: the backend refused the authentication header. Re-copy the key from your vendor.
* **Wrong path or protocol**: the URL doesn't point at an OTLP logs intake, or the backend wants the other wire format. Check the endpoint against your vendor's docs and try switching the protocol.
* **Partial rejection**: the backend accepted the request but refused the record. The message includes what the backend said.
* **Unreachable or timed out**: nothing answered at that address. Check the hostname and any IP allowlists on your backend.
* **Blocked target**: the endpoint resolves to a private or internal address, which Alpic refuses to push to. Use a publicly reachable hostname.
* **Backend error**: the backend answered with a server error. This is usually transient, so retry in a moment or check your vendor's status page.
* **Invalid payload**: the backend could not parse the payload. This is likely an Alpic bug, so contact Alpic support.
* **Anything else**: the message carries the backend's exact answer. This result is not retried automatically, so check it against your vendor's OTLP documentation.

## What gets exported

Every line your server writes to stdout or stderr becomes one OTLP log record.

The severity comes from your line itself when it is structured JSON with a `level` or `severity` field. For plain-text lines it is inferred: everything written to stderr arrives as an error, and a stdout line arrives as a warning if it mentions `warn`, as debug if it mentions `debug`, and as info otherwise. Structured logging therefore gives you the most predictable severities.

## Plans and downgrades

Logs export requires a paid plan. If your team downgrades, export stops but your configuration is kept, and upgrading resumes export with nothing to re-enter.

To stop exporting on any plan, delete the destination.

## When a destination stops being retried

If a destination keeps failing, whether from a revoked credential, a decommissioned endpoint, or a vendor outage that does not end, Alpic stops retrying it and says so in the Telemetry section, along with the reason it stopped. A rejected credential or a wrong path stops it immediately, since neither recovers by being retried. A temporary failure has to persist for a long run of batches first.

Its siblings keep exporting. To start it again, fix the endpoint or the headers and save, or click **Send a test log**: either one clears the state once it succeeds. Logs written while a destination is stopped are not replayed to it.