Checkly is now a connector in Honeycomb Canvas. October 27, 2026 Honeycomb recently launched Canvas connectors, with Checkly serving among its first group of integration partners. With the Honeycomb Canvas connector for Checkly, the Canvas Agent can bring your synthetic monitoring into an investigation to help determine which checks are failing, from which locations, since when, and what Rocky AI identified as the likely root cause. And when an investigation finds a gap in your synthetic monitoring, the agent can even create a new check or update an existing one to close it, without leaving Canvas. Canvas is Honeycomb's AI-powered investigation workspace, where engineers and the Canvas Agent work the same problem side by side. Honeycomb built the Checkly connector on top of the Checkly MCP server. Its part was making Checkly readable and usable by an agent. Their part was everything that makes it useful in the middle of an incident such as how the agent decides when to call Checkly, how results show up in Canvas, and how anything that changes your account gets approved first. That was the harder part, and Honeycomb got it right. Checkly Inc. tried it before launch and were impressed by how well it works. "Adding the Checkly connector to Canvas was one of our easiest integrations. Their MCP server is spec-compliant, works well, and its concise, reliable tools help the Canvas Agent make better decisions," said Taylor Pratt, Product Manager at Honeycomb. Honeycomb shows you what happened inside your system. During an incident, the first question is often about the outside. Did checkout actually break for users in Frankfurt? Which region saw it first? Synthetic monitoring answers that. Checkly clicks through your app like a user, with Playwright browser checks, API checks, and uptime monitors running on a schedule from 20+ locations, whether or not real traffic is hitting the app. Checks retry before an alert fires, so when one fails, something real broke. Until now, that signal lived in another tab. A user would need to open Checkly, find the failing check, and paste the result into the incident channel. Usually the person on call, usually at a bad hour. The Canvas Agent can read your checks, assessing results, incidents, status pages, and Rocky AI root-cause analyses. It can also create and update checks, run a check, or start a new root-cause analysis, with your approval. In an investigation, that means it can: * See which checks are failing right now, and from which locations. * Pull a failed run with the error, the step that broke, and when the failures started. * Read what Rocky AI found, including the likely root cause and the user impact, or start a fresh analysis. * Look at your status pages. Have customers already been told? * Re-run a check after the fix ships, so you know the flow works again before you close the incident. * Create a check for a flow that had no coverage, or update one whose timeout or locations no longer fit. Here's a real example. In a demo environment running the OpenTelemetry Astronomy Shop, Checkly Inc. asked the Canvas Agent: "A number of my synthetics are slow and degraded. Can you investigate both the synthetics and the telemetry data you have around these to determine what is going on?" The agent found four degraded Checkly API checks, all hitting the product catalog service. It noticed the slow runs landed at 11 minutes past every hour, which pointed to something scheduled, and lined that up with an hourly Playwright check suite. It pulled Checkly's root-cause analyses for the failing runs and followed one slow trace in Honeycomb to see where 15 seconds went: almost all of it was waiting, not working. The answer: the Checkly private location running the Playwright suites shared one small machine with the shop, so every heavy suite run slowed the product catalog down. One question, one correlated timeline, both sides of the story. Reads run without asking. Anything that does something in Checkly, like triggering a check run or creating a new synthetic, waits for your approval each time. You can change that per tool in Canvas (Always allow, Ask, or Never). Yes. Most incidents end with a fix and a note to "add monitoring later," and later rarely comes. In Canvas, you can close the gap in the same place you found it. Ask the agent to create a browser check for the flow that just broke, or to update a check that no longer fits. In the example above, a natural follow-up is: "Update the synthetic to fail after 20 seconds and mark it degraded above 5 seconds." The agent shows you the change and asks for your approval first. Once you approve, it's a real Checkly check, live in your account. If you manage your checks as code with the Checkly CLI, add the change to your repo too. The next deploy from your project overwrites changes made outside it. You need a Honeycomb account with Canvas and a Checkly account. Setup takes about a minute: * In Honeycomb, go to Canvas > Connectors. * Find Checkly and select Connect. * Sign in to Checkly and approve access on the authorization page. The connector shows a Connected badge when it's done. Then open an investigation and ask about your checks. Something like: "Are any Checkly checks failing for the checkout flow right now?" Each teammate connects their own Checkly login, and the agent only sees what that person can see in Checkly. If you belong to more than one Checkly account, name the one you want in your prompt. There's no API key to copy. You sign in with your usual Checkly login. Honeycomb's Checkly connector docs cover the rest. Not on Checkly yet? Start free and have your first check running in a few minutes, then connect it to Canvas. Good. The two work in opposite directions, and they fit together. Checkly can already export check traces to Honeycomb over OpenTelemetry, with the check ID on every span. A red check in Checkly becomes a query in Honeycomb in one click. The Canvas connector goes the other way: from inside your investigation, the agent reaches into Checkly for the check results, the root cause, and the status page. With both on, Canvas has the trace and the check that caught the failure in the same place. Honeycomb and Checkly serve the same teams: engineers who own reliability and want tools built around how they actually work. Honeycomb gives them the inside view. Checkly gives them the outside view, what users actually saw. Checkly Inc. don't build trace analysis, and Honeycomb doesn't build synthetic monitoring. Canvas is where the two meet. Checkly Inc. opened up Checkly through its MCP server so tools like Canvas could build on it. Seeing a partner take that and ship something this good at launch is exactly what Checkly Inc. hoped for. Thanks to Taylor Pratt, Ronald Ekambi, and the Honeycomb team who built Canvas connectors, and for including Checkly Inc. at launch. If you run both, connect Checkly in Canvas and try it on your next investigation. If you run Honeycomb and want the outside-in signal, start free with Checkly. Either way, tell Checkly Inc. how you use it in its community Slack. Director of Global Alliances at Checkly Senior Solutions Engineer at Checkly Try Checkly Catch it before your users do. Run Playwright and API checks against production every minute, from locations around the world. Your checks live in your repo and deploy with your code. Free plan. No credit card. # scaffold a project with example checks $ npm create checkly@latest # run them from its global locations $ npx checkly test # turn them into production monitors $ npx checkly deploy

Honeycomb unveils new AI observability features to close the gap between shipping agents and understanding them. New AI Ecosystem gives teams fleet-wide visibility into agent health and cost; Canvas expands with new MCP connectors for deeper investigative context. Honeycomb.io, the observability platform for the new shape of software, announced new features designed to help DevOps and engineering teams find and fix issues in production before their customers do. The release introduces Honeycomb's new AI Ecosystem, which provides a fleet-wide view of all of your AI agents in production, their performance, costs and individual conversations, while new Canvas MCP connectors bring context to your telemetry data. "Teams are shipping agents faster than they can see what those agents are doing," said Graham Siener, SVP of Product at Honeycomb. "You can't govern what you can't see. AI Ecosystem gives you one view of failure rates, costs, and behaviors of every agent you run, including the ones that haven't caught fire yet. Even better, it also allows you to go straight down to the conversation that caused an issue. When something needs a closer look, Canvas connectors put the code, tickets and team discussion right next to the telemetry, instead of scattered across five other tools." Managing a Multi-agent Fleet with Honeycomb's AI Ecosystem Organizations are releasing and deploying agents at a blistering pace. According to a recent survey conducted by Honeycomb, 71% of respondents said they're deploying AI agents faster than their ability to manage or govern them. Engineering teams need to be able to answer critical questions quickly such as: * Which agent is degrading, and is it one agent, or fleet-wide? * Is this a real regression or normal variance? * Which customers are directly affected? Sep 29, 2026 Prev Next 1 of 43,656 Honeycomb's AI Ecosystem gives teams a diagnosis layer for an entire fleet of agents in production, providing a continuous, aggregate assessment on failure rates, token usage, latency, and cost across every agent. Because it's built on Honeycomb's high-cardinality data model, teams can drill down into individual agent conversations seamlessly from a high-level fleet view. At launch, AI Ecosystem contains three core features, including Agent Fleet Performance, LLM Cost Tracking, and Agent Conversations (previously known as Agent Timeline). These collective capabilities provide full context and dynamic granularity on fleet-level health, per-agent health and volume, cost and efficiency, latency and performance, and blast radius. Bring More Context into Canvas Investigations AI is accelerating code generation, tripling the shipment of code and production issues, and adding more toil on engineers on call.* To help teams respond faster, Honeycomb is expanding Canvas, its multiplayer workspace, with new MCP connectors. These connectors provide context beyond production telemetry. They add details like source code, IT and support tickets, design rationale, live team conversations and more. Connectors available today include GitHub, Linear, Pylon, incident.io, Atlassian, Braintrust, Sentry, Amplitude, and Checkly. Unlike single-user, chat-based agents, Canvas allows teams to work collaboratively to view the same telemetry artifacts, edit queries, verify agent prompts, check tool invocations and more. It's designed for the realities of investigating complex production environments, where teams of humans and agents need to operate off of shared context. "Canvas gives you that unified look of this is the problem I'm trying to solve, these are the queries I threw at it, the questions I gave it," George Luong, Senior Engineering Manager, Observability at Slack. "You can see the thought process. You see the charts that it's plotting out." [To share your insights with AiThority, please write to [email protected]]

What customers are doing with AI and Honeycomb. At O11yCon, Honeycomb talked to engineering teams across the industry, and the numbers are starting to get genuinely wild: Mixpanel DevOps Engineer Eddie Bracho told Honeycomb their engineering team is generating 50% more PRs than before AI came into the mix (sorry). | June 30, 2026 Contents. Conference Talks June 4, 2026 Nathen Harvey shares DORA report results at O11yCon 2026. Watch this highlight reel of Nathen Harvey, DORA Lead and Product Manager at Google Cloud, talking about results from the most recent DORA report at O11yCon 2026. At O11yCon, Honeycomb talked to engineering teams across the industry, and the numbers are starting to get genuinely wild: Mixpanel DevOps Engineer Eddie Bracho told Honeycomb their engineering team is generating 50% more PRs than before AI came into the mix (sorry). That kind of velocity is exciting, but it's also a pressure test for every part of your stack that isn't writing code, including your observability practice. Here's what Honeycomb is hearing from customers about how that's playing out. Code volume is the new forcing function. Eddie put it plainly: the investment Mixpanel had already made in observability infrastructure is what's letting them absorb the new volume. "We still have the same number of engineers. They're just writing more code now. Being able to rely on Honeycomb there has been really great." Observability isn't just a "nice to have" anymore. When your deploy frequency jumps 50%, you need to be able to tell quickly whether a new change is behaving as expected or if it's misbehaving. The feedback loop either keeps up or becomes the bottleneck. Yi-an Lai, Engineering Manager at Gem (a recruiting tech platform), framed it well: "Shipping code is just a little part of an engineer's job. We also do code reviews, design complex interconnected systems, and a big part of our job is participating in on-call rotations where engineers help triage and solve customer-reported issues. We may be faster at shipping code, but it is critical for us to also become faster and more efficient in supporting our product." AI helps with the left side of the loop. The right side, understanding what your code is doing once it's out in the world, still needs work. The Honeycomb MCP server. Several of the teams Honeycomb talked to have been connecting the Honeycomb MCP server to their AI coding agents, and the use cases are interesting. At Gem, Yi-an's team built AI-assisted tooling to help engineers during on-call rotations: "Instead of just reasoning with static code, it's able to gather concrete evidence, or it's able to dive deep into traces to uncover performance bottlenecks." Mixpanel is building toward an incident triage bot. The goal: whenever there's a page, automatically open an agent session, pull in data from Honeycomb alongside GCP logs and Kubernetes, and surface as much context as possible before a human even opens their laptop. "How do I surface as much context as possible to an engineer?" is how Eddie described it. The Honeycomb MCP server is a core component of that. StarSling (which builds faster, cheaper GitHub Actions via a self-improving CI loop) has gone the furthest down this path. Their Co-founder Daniel Worku described an interesting approach: start with the Honeycomb MCP server, layer on the Honeycomb skill that wraps the MCP with sub-agents and prompts, then build a custom skill on top of that with specific context about how their architecture works. "When we have an incident, I can just run that skill. I'm like, 'what's going on?' And we usually get an intelligent answer out the backend." The progression from raw MCP access to a bespoke, context-rich skill is something Honeycomb expect to see more teams working through. BubbleUp for Bubble. One thing Shogo Wada at Bubble told Honeycomb deserves attention. Bubble is a no-code platform, which comes with its own challenges: AI doesn't know the company's proprietary language, which makes instrumenting agents harder. But for their backend systems, Honeycomb has become useful in a specific organizational way. "Before Honeycomb, we were using logs and metrics. There were a few engineers who could see the patterns in the dashboard and come to a conclusion. But they needed to spend years at the organization to get there. With Honeycomb, anybody can see the correlation and come to the conclusion and go from there." BubbleUp, specifically, comes up a lot in conversations like this. Finding the signal in high-cardinality data used to require deep institutional knowledge. When that knowledge is encoded in a tool anyone can use, you stop depending on the two people who've been around long enough to read the tea leaves. Reactive now, proactive next. Most teams are honest that their current AI-assisted observability workflows are still reactive. Yi-an at Gem said as much: "A majority of it is reactive, but our team is also currently going through a revamp of our frontend observability stack. We're adopting OpenTelemetry, and with this transition, we expect to first standardize and then switch from reactive to proactive monitoring." That's the arc Honeycomb keep seeing: instrument properly, standardize on OpenTelemetry, get the data rich enough that AI can start surfacing things before a customer notices. Right now, most teams are using AI to go faster once an alert fires. The teams further along are working toward AI that catches things before the alert even needs to fire. The infrastructure needs to be there first, though. You can't ask an agent to reason about your system if your telemetry is incomplete, inconsistent, or siloed across three tools that don't talk to each other. What this actually requires. Rich, high-cardinality telemetry is the foundation everything else is built on. Observability is only as useful as the data behind it. The good news is that the teams doing this well aren't running exotic infrastructure: OpenTelemetry, distributed traces with enough context attached, and SLOs that measure the customer experience rather than just server health. The AI tooling on top of that is increasingly accessible, but the data quality underneath it still requires deliberate investment. If your AI coding agents are already shipping 50% more code, that investment is probably due.