Move from Sentry

Keep your existing Sentry SDK and error-capture calls. Create a Bicho project, replace the DSN, and send new errors to your own Cloudflare account. You investigate them through Bicho’s MCP tools or HTTP API, not a dashboard.

This redirects new events. It does not import historical Sentry data, issue statuses, or project settings, and Bicho’s grouping rules differ from Sentry’s.

Replace the DSN

1. Deploy Bicho and create a project. Use secret: false for browser applications.
2. Save the returned sentry.dsn. It contains your Bicho instance’s hostname, the project’s public ingest key, and its generated project ID. Do not reuse your Sentry-hosted DSN.
3. Set your SDK’s DSN to that value. Keep error-capture integrations and remove integrations that send tracing, replay, profiling, or structured logs.

For an application already using @sentry/browser or @sentry/node, keep its existing import and update initialization:

Sentry.init({
  dsn: 'https://YOUR_PUBLIC_KEY@your-bicho-worker.example/PROJECT_ID',
  tracesSampleRate: 0,
  sendClientReports: false,
});

Use the generated DSN, not the placeholder above. Preserve your application’s release, environment, tags, filtering hooks, and error-capture options. Remove any custom tunnel or transport destination that would still send events elsewhere. Disable replay, profiling, tracing, structured logs, and automatic session tracking where your SDK enables them; tracesSampleRate: 0 only disables trace sampling. Option names and defaults depend on your SDK.

Bicho’s interoperability tests cover @sentry/node and @sentry/browser 11.8.0 serialization and transports, including real HTTP delivery and browser-client delivery inside workerd. Other SDKs depend on their transport and emitted event format; Bicho does not claim compatibility with every Sentry SDK or integration.

Secret-enabled backend projects

A project created with secret: true also returns sentry.headers, containing X-Bicho-Secret. Pass those headers through your SDK’s transport configuration. With @sentry/node, using the saved project-creation response:

Sentry.init({
  dsn: project.sentry.dsn,
  transportOptions: { headers: project.sentry.headers },
  tracesSampleRate: 0,
  sendClientReports: false,
});

A DSN alone cannot authenticate a secret-enabled project. If your SDK cannot send custom headers, use a public-key-only project or a transport that supplies the backend secret. Never put an ingest secret or the admin token in a browser bundle. The admin token is not an SDK credential.

Save the generated DSN and any backend headers securely. Project listings omit credentials; creating another project does not recover the old credentials.

Check delivery

Send a clearly named event from your application and await the SDK’s flush before shutdown:

Sentry.captureException(new Error('Bicho setup check'));
const delivered = await Sentry.flush(5000);

Use the SDK’s delivery result and network diagnostics, then read the stored event through your instance’s MCP or API. Search the correct project and time range; use status: "all" when searching issues. An SDK-generated event ID or a successful flush alone does not establish that Bicho stored the event. HTTP 200 can include rejected events, and standard SDKs may ignore that response body.

What Bicho keeps

Error and message events go through the same credential filtering, quotas, grouping, append-only storage, and investigation tools as OTLP events. Captured evidence can include:

• Exceptions and stack frames.
• Release, environment, tags, and custom fingerprints.
• Breadcrumbs, contexts, and other event fields supplied by your SDK.

Bicho does not reproduce Sentry’s grouping rules, built-in UI, or alerts. Transactions, sessions, replay, profiling, structured log items, attachments, and other unsupported envelope items are discarded without storing their payloads. Minidumps and Sentry artifact-bundle uploads are unsupported.

For JavaScript source maps, captured frames or debug_meta.images must supply matching debug IDs and generated positions. Upload maps through Bicho’s authenticated source-map API; pointing Sentry’s artifact uploader at Bicho is not supported. A release label or DSN change alone does not enable mapping.

Sentry SDKs can collect more context than the Bicho JavaScript SDK, including breadcrumbs and request or user data depending on configuration. Review your integrations and filtering hooks before switching. Bicho’s credential filtering is not a general personal-data scrubber. See privacy and credentials.

Transport and limits

Bicho accepts POST /api/:project_id/envelope for Sentry envelopes and POST /api/:project_id/store for raw legacy JSON events. Both accept a trailing slash. Authentication supports protocol-v7 query credentials or X-Sentry-Auth; envelopes can also authenticate through their header’s DSN. All supplied credentials must agree with the route project, and an envelope DSN must use this installation’s origin. The server does not forward ingestion to Sentry.

Requests support gzip and deflate through Content-Encoding, not Brotli, zstd, or base64-wrapped legacy bodies.

Limit	Scope
2 MiB	Wire body and decompressed body, independently.
1 MiB	Each error event and its normalized stored payload.
100	Items per envelope, including unsupported items.
32	JSON nesting levels.
20,000	Structural values per parsed JSON object.

Malformed error events reject the batch before persistence. Successful responses contain accepted event IDs, rejected event IDs, and discarded counts for unsupported items.

Before any acceptance, quota exhaustion returns 429 with Retry-After and X-Sentry-Rate-Limits; storage failure returns 503. After an accepted prefix, the response is HTTP 200 with rejected IDs rather than a whole-envelope retry signal. Standard SDKs may ignore the body and drop the rejected remainder. Monitor rejection counts as well as HTTP status. If explicitly resending individual events, preserve their event_id so retries deduplicate within the project.