Skip to main content
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.
Logs export is available on paid plans. Destinations are configured per environment, so staging and production can point at different backends.

​
Set up a destination

1

Open the Telemetry settings

In your project Settings, open the Telemetry section and pick the environment to configure.
2

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

Pick the protocol

HTTP/protobuf is the OTLP default. Switch to HTTP/JSON only if your backend asks for it.
4

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

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.

​
Common vendors

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

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