Working with Webflow CloudObservability

Sentry

Track errors and traces for your app with Sentry

Sentry adds error tracking, structured logs, and tracing on top of the runtime logs you already get with Webflow Cloud. Reach for it when you want alerts, grouped error reports, or traces that follow a request from the browser into your server code.

Setup is close to Sentry’s standard framework guides. The differences come from running on the Cloudflare Workers runtime, and they’re the kind of thing that silently breaks if you don’t know about them, so they’re called out in Webflow Cloud caveats at the end.

Every framework has a ready-to-run example on the sentry branch of its starter repo. If you just want to see Sentry working, deploy one and set your DSN. See Example branches.

Set up Sentry

1

Create a Sentry project

In Sentry, create a project and copy its DSN. Pick the platform that matches your framework (for example, Next.js) so you get the best stack traces.

2

Add the Sentry SDK

The browser side is the same everywhere: initialize @sentry/browser with your public DSN. The server side depends on your framework.

Use @sentry/nextjs, following Sentry’s manual setup and its Cloudflare/OpenNext guidance. One extra step matters on Webflow Cloud: give the server a fetch-based transport in sentry.server.config.ts, or server events get dropped. See Webflow Cloud caveats.

To see the full wiring, look at the sentry branch of the Next.js starter.

3

Set the DSN environment variables

Sentry needs your DSN in two places: in the browser bundle at build time, and available to the server at runtime. Set these in your app’s environment variables.

Set NEXT_PUBLIC_SENTRY_DSN. Next.js inlines NEXT_PUBLIC_ variables into both the browser and server bundles, so this one covers both sides.

Optional: set SENTRY_ORG, SENTRY_PROJECT, and SENTRY_AUTH_TOKEN to upload source maps during the build and get readable stack traces.

4

Deploy and verify

Deploy your app:

webflow cloud deploy

Then open your Sentry project’s Issues and Logs views. Trigger an error in your app (the example branches include a button that throws one), and confirm it shows up in Sentry within a few seconds.

Webflow Cloud caveats

These come from running on the Cloudflare Workers runtime (workerd) instead of Node. They’re what trips people up when they follow Sentry’s stock framework docs.

Node-transport SDKs drop server events silently

Sentry’s default server transport (used by @sentry/nextjs and other Node SDKs) sends events with Node’s https.request, which workerd only supports at newer compatibility dates. Webflow Cloud currently deploys with an older one, so out of the box server-side events are dropped with no error. Fix it by overriding the transport with a fetch-based one, the way the Next.js example does in sentry.server.config.ts. SDKs built for Cloudflare (@sentry/cloudflare, used by the Astro and Vite examples) already use fetch, so they work as-is.

Astro: use middleware, not the worker entry

Sentry’s Cloudflare docs point wrangler.json#main at a wrapper file, but Webflow Cloud owns the worker entrypoint and discards that wrapper at deploy time. Wire Sentry through Astro middleware (Sentry.wrapRequestHandler) instead, so it runs inside whatever entry the platform uses.

Don't use Sentry's tunnelRoute

tunnelRoute registers the tunnel at a fixed path that ignores the mount path your app is served under, so it won’t resolve. Leave it off.

Example branches

Each starter repo has a sentry branch with a working setup, validated on the Workers runtime Webflow Cloud deploys with:

The Astro example currently targets Astro 6. An Astro 7 version is in progress.