What a server SDK captures
- Errors: unhandled exceptions in requests, background jobs and threads, plus errors you report yourself. Grouped by your own code, so library frames don't split issues.
- Incoming requests: every request your service handles, by route (for example
/orders/{id}), with status, latency and size. Find them on the Network page under Requests your servers receive. - Outgoing calls: requests your service makes to other APIs, with status, latency and failures, on the Network page under APIs your apps call.
Errors are included on every plan. Request and API call monitoring follow the network monitoring on your plan (Starter and up), with the same sampling. Failed requests are always kept.
Languages
PythonDjango, Flask, FastAPI and Celery.Node.jsExpress, Fastify, NestJS and Next.js.Java & KotlinSpring Boot, Servlet, OkHttp.Gonet/http, Gin and Echo.PHPLaravel, Guzzle and plain PHP.OpenTelemetryTraces and error logs over OTLP from any language.
Using another language? Send traces and error logs with OpenTelemetry, or events directly with the Ingest API.
Which key to use
Use the project's public key (cs_live_pk_…, or cs_test_pk_… for a test environment), the same kind of key your apps use. Never put a secret key in a service: the SDKs refuse it. Create a separate project for each backend service so its issues and routes stay apart.