---
title: Connecting Cloudflare and Honeybadger with OpenTelemetry
published: "2026-10-29"
publisher: Honeybadger
author: Addison Curtis
category: DevOps articles
tags:
- Honeybadger
- Insights
description: "Cloudflare's built-in observability works fine for small apps, but the search is clunky and your data gets split across events and traces. Here's how to pipe Cloudflare Workers logs into Honeybadger Insights with OpenTelemetry instead."
url: "https://www.honeybadger.io/blog/cloudflare-honeybadger-otel/"
---
[Honeybadger Insights](https://www.honeybadger.io/tour/logging-observability/) is pretty great. It's even greater when you connect it to [Cloudflare](https://www.cloudflare.com) and start shipping logs directly from Cloudflare Workers to Insights. If you're already using Cloudflare to distribute your applications, it's easy to set up.
Cloudflare Workers logs capture what your application is doing at the edge: `console.log()` output, uncaught exceptions, and system-generated logs for each request. That data can be very important for your application's health — especially for web apps in distributed systems. Insights gives you the tools to act on it.
In this article, we'll use [OpenTelemetry](https://opentelemetry.io) to connect Cloudflare and Honeybadger. For that, we need a test app. We'll make one using RedwoodSDK.
[RedwoodSDK](https://rwsdk.com) is a server-side React framework described as "a framework for humans." It's a breeze to spin up if you already have Node.js installed — with just a few commands, you can get a server up and running.
Deploying it is just as easy. Once you have a Cloudflare account ready, push everything to production with `npm run release`.
As specified in [RedwoodSDK's documentation](https://docs.rwsdk.com/getting-started/quick-start), I had to complete the additional step of creating a `workers.dev` subdomain, but it still worked on the first try. No bugs or troubleshooting needed.
## Why you should connect Cloudflare to Honeybadger Insights
Cloudflare already has an observability page, so for small web applications, you could stop there. For bigger applications, Cloudflare's observability page may not be enough, since its tooling is relatively shallow. It splits your data between logs and traces, making it harder to find and fix errors. Additionally, the query builder is fragmented, so it's hard to save visualizations for repeat access.
Honeybadger Insights makes log analysis _that_ much easier. Insights has everything you need: a powerful query system, natural language search, easy visualization generation, and configurable alarms. Forget separating data into logs and traces — Insights uses _wide events_, each one a collection of properties bundled into a single record. User behavior, business intelligence, system logs, and Cloudflare Workers logs can all be sent to Insights.
## OpenTelemetry: the glue that makes it all work
OpenTelemetry (OTel) is an open-source observability framework for cloud software. Insights supports the [OpenTelemetry Protocol](https://opentelemetry.io/docs/specs/otlp/) (OTLP), including traces, metrics, and logs; for this example, we'll focus on logs. Like most OTLP log destinations, Insights uses an endpoint ending in `/v1/logs`: `https://api.honeybadger.io/v1/logs`. We'll use this for our guide, but you'll also need an API key, which can be generated in your project settings.
Cloudflare also supports OTel, specifically traces and logs. We're interested in the logs, which Cloudflare describes as "...application logs, including `console.log()` output and system-generated logs." You can read more about their logging methods in [Cloudflare's documentation](https://developers.cloudflare.com/workers/observability/logs/).
Now let's hook it all up.
## Setting up log exports
The process starts once you've created a RedwoodSDK app and deployed it to Cloudflare. In the sidebar of your Cloudflare account, find the **Observability** tab under the **Compute** dropdown.
_Scroll down from Account Home to find the Compute section._
The page will show an events timeline that can be configured for live log tailing, searching, or sorting.
Navigate to the **Destinations** sub-page. Now, it's time to create a destination.
Click **Add destination**, then switch over to the **Logs** tab. Next, head back to your Honeybadger account. Each destination sends logs to a single Honeybadger project, and a project's API key is located under the **Settings** tab in the project's top menu. From there, navigate to **API keys** and generate a new key. You can label it, too — I named mine `cloudflare`.
Now armed with an API key, we can return to the Cloudflare page and start filling it out. In the input field for the **OTLP Logs Endpoint**, copy and paste `https://api.honeybadger.io/v1/logs` as the address. Name the destination whatever you want, then add a custom header.
For the custom header name, enter `X-API-Key`, and for the value, paste your API key. The header name must be exactly `X-API-Key`, or Honeybadger will reject the logs. Once you click **Save**, Cloudflare will run an internal check. If everything is filled in correctly, the destination will save successfully.
_Voilà!_ We have a working log pipeline between Cloudflare and Honeybadger. Now we can monitor our Worker's activity much more easily.
## Integration testing
Cloudflare may say that our log pipeline works, but we need to be sure we're receiving logs. Let's define a log line, trigger it, and then make sure we're ingesting it.
I added this route to my `src/worker.tsx` file, in the route section:
```tsx
route("/hello", function () { console.log("Hello world!"); return new Response("logged"); }),
```
If you've followed RedwoodSDK's quick start, the route section should look like my example below.
```tsx
render(Document, [ route("/", () => new Response("Hello, World!")), route("/ping", function () { return Pong!
; }), route("/hello", function () { console.log("Hello world!"); return new Response("logged"); }), ]),
```
We can now prompt our Worker to generate a "Hello world!" log. I ran `curl -s https:///hello` and then checked Cloudflare to make sure the message was recorded before moving over to Insights.
Events won't appear in Insights right away — give Cloudflare a few minutes to ship them over. Check it out!
Clicking on the Insights tab brings up the default view, and since this is a dummy project, I have no other results. If you had other integrations sending data, you could filter by `event_type`, or filter on a specific message like "Hello world!" For logs, severity is an excellent filter, too.
## Everything else Insights can do
Now with Cloudflare and Honeybadger connected, our logs will flow into Insights, where they can be sorted and measured. We can even turn them into widgets to track errors, API activity, and more. The more you integrate with Insights, the more you can observe and act on. Connecting your Workers to a monitoring service is always a good idea, allowing you to catch problems before they affect your customers.
Why not use Honeybadger for monitoring? It's easy to install and set up, no matter [what framework you're using](https://docs.honeybadger.io/lib/). Try it — it's free to [make an account](https://www.honeybadger.io/plans/).
---
## Try Honeybadger for FREE
Intelligent logging, error tracking, and Just Enough APM™ in one dev-friendly platform. Find and fix problems before users notice.
[Start free trial](https://app.honeybadger.io/users/sign_up)
[See plans and pricing](https://www.honeybadger.io/plans/)