Cursor x Datadog

0:01 All right, we'll give it 1 minute or so, but I I feel like folks will probably float in as as we start. Um, thanks folks for joining again. Really happy to have you all for this exciting workshop. Um, I'll do a quick intro and then Tib will go and we'll get started from there. Um, there will be a recording posted after. Uh, so if you have to drop early, no worries. Um, again, I'm Amrita. I'm calling from the Cursor office in lovely San Francisco. I'm a

0:28 field engineer. Meaning that I kind of go out and do workshops, trainings, and I help customers get the most out of Cursor. Um, and I'm here joined by Tib. Cool. Hello everyone. Um, so I'm Tib. I'm a product manager at Datadog, um, working on the error tracking product.

0:47 Um, I've spent the last few years thinking about how engineering teams find and fix production errors and how to fix them faster. And I think, you know, with Amrita today, uh, we get to show you something that I think changes that, um, significantly. All right. Uh, let me share my screen quickly.

1:09 Uh, cool. So let me talk a little bit about the problem we are trying to solve here. Um, so the part of incident response that's, um, the hardest to justify is not the fix per se. Um, it's everything that comes before that and especially the, uh, very long time that it takes to know what to fix. Um, because you need to read the stack trace, you need to correlate deploys, you need to pull lots and lots of logs. I know a lot of you have been, uh, through this painful process. Um, and the thing is that it actually

1:42 follows the same steps every time and that is very frustrating, but it also useful because it means it's predictable and therefore it means it's automatable. And that's what we are going to demonstrate today. Um, I just want to talk a little bit about the impact of bugs. Um, as a product manager, this is particularly, uh, important to me. Um, obviously bugs affect real users, right? Whether this is a, uh, a a failed checkout funnel or broken flows, sessions that just end.

2:15 And so the longer it takes to resolve, the larger the blast radius. And so shortening this, um, resolution loop has a direct business impact. So very important for engineers, very important for business to actually making sure that the resolution loop is as short as possible.

2:34 Um, and I think, you know, right now, this is a more pressing problem than ever. Um, AI coding tools mean it actually that the tools mean that teams are shipping more code and shipping it faster. And that's the whole point. It's absolutely amazing and you know, here at Datadog, we love using agents and especially Cursor.

2:55 Um, but agents also mean more deploys. Right? And so this is more surface area, this is more potential for something to break in production. And so this resolution loop I was talking about has to keep pace with the shipping loop. Um, so how do we do that? Um, let me talk a little bit about error tracking because, uh, this is how Datadog can help agents investigate errors. So, uh, before it can shorten this loop, an agent needs a good signal. Um, and this

3:33 is what error tracking provides. We're not a log viewer. Um, error tracking is the thing that turns thousands of raw error events into a structured issue a machine can reason about. It's um, really this meta, um, object that is much more, uh, much richer than a single event.

3:57 In production, errors are not unique, right? Um, and so a single bug might fire thousands of times across different users, um, different services or different environments. And if you don't group those events, every one of them is a separate entry. Um, you cannot track them over time and alert quickly become, uh, very noisy. Um, and so this is how error tracking, like this is the problem error tracking is tackling and let me show you how we actually solve this in practice. Um, so jumping to Datadog into the error

4:32 tracking, um, page, um, you can see that errors are grouped into issues and you have a backlog of those issues, right? Very standard, very simple. Um, what it's what is interesting to look at here is that those issues are sorted by impact. You can sort by impact sessions. You can also sort by different dimensions and, um, decide what fits your, uh, workflow best here. Um, so what I really want to highlight again is that instead of having 10,000 logs, you have one single issue you can

5:05 take a look at. And same thing for agents. Um, and there's very little need for manual triaging given this sorting, um, option. So let me open, uh, the first issue and actually I might open this full page. So we have a little bit more visibility here. Um, so what you can see here is the, um, history of all the, um, errors that, um, fired. What's also very interesting, again, taking this meta approach to issues, um, is that you can have an evaluation of, um, the impact it has, right? So, oh, for instance, this one is

5:43 affecting, uh, 26% of users. Oh, that's pretty significant, but it's not one, it's not 100%. So you might actually decide differently based on that. Another thing that it's doing at the issue level is tags. So we do, uh, analysis on tags and we can surface, um, different dimensions that might be very helpful when investigating. So for instance, here I've highlighted, uh, the countries that were the most affected by the issue, um, and you know, this might

6:14 heavily inform again the investigation and help debugging. Same thing with the browser name, the version and so on. You can add a lot of dimensions that are, um, very useful. Um, so that was that's what we call the tag breakdown. Uh, what else do I want to show? Um, let me jump to Oh, yeah, this issue I think has something interesting. Um, so we do something that is called, uh, the suspect commit. We are able to identify, uh, what is the most likely, uh, culprit for the bug, right? Looking

6:51 at the, uh, the Git history and we can flag the, uh, the the relevant commit and even the, uh, the author of it. So we it's we can proactively reach out to to them and let them know that, uh, they probably introduced something that, uh, broke production. Um, and that's something everything I'm showing here is something that will be surfaced to agents, by the way. Um, and you know, that's something that's going to be incredibly useful for automated

7:15 debugging. Um, do do do. And so, yeah, what basically, you know, there are also, um, the stack traces, which is, um, one of the most, if not the most important, uh, piece of information that, uh, you need to look at when investigating an issue. And one thing that I wanted show here is that, uh, we have a feature called, uh, exception replay that again the agent has access to, which allows, um, the user and the agents to understand what were the values for the variables when the exception occurred.

7:50 Uh, and that's something that's very useful to really understand, okay, uh, what happened exactly during the prob the, um, the the, uh, the issue and how to actually reproduce that locally because it's always this massive gap between, oh, that happened in production, but I cannot reproduce this locally, which we've all been through. Um, so yeah, so basically that's, uh, that's, uh, the error tracking part. Um, what I think I want to show here as

8:19 well is talk a little bit more about the MCP and how, you know, Datadog and Cursor work together to provide this, um, automation experience. Um, something that I've briefly talked about is our No, actually I haven't talked about it. So let me just, sorry, um, go back a little bit. I want to talk about our investigation capabilities. We have something that's called Bits AI and we investigate production issues. So what a question I think it's fair to ask is

8:46 whether Bits and Cursor agents are doing the same thing. Is that, uh, you know, competition? And in practice, they're not doing the same thing. Um, Datadog's advantage is the runtime visibility, right? Uh, we see the system as it actually behaves in production. Um, and it's not the code as written, but the code as, uh, it runs.

9:11 And so this means we see real users, real request payloads, real, um, infrastructure state at the moment of failure. Uh, we for instance know which version introduced the error, that's something I showed, um, what the execution context look like or which region or user segment is affected, right? Um, static code analysis cannot tell you what value a variable had at the moment, um, of crash or whether it started, you know, uh, after deploy at 3:00 p.m. on

9:42 Tuesday. And so those require observing live system and this is where Datadog helps. Um, Cursor on the other hand has a great advantage when it comes to the code base. It can read it, it can reason about it, it you change it. And so our demo today is um, demonstrating a workflow where each tool does what it's actually best at.

10:04 Datadog surfaces the runtime evidence, and Cursor acts on the code. And the MCP here is the handoff between the two. So, um I think that's it on the Datadog side. Amrita, over to you for uh the Cursor demo. Awesome. Thanks, Tib. Um that was a great segue. We're going to start by actually looking at the Datadog MCP within Cursor. I'm going to talk a little bit about how you can use it and make the most out of it, and then we're actually going to talk about a relatively new feature in Cursor called

10:35 automations and how you can actually leverage Datadog in your automations to make a lot of these workflows more seamless um and a lot more uh natural for you all. Um feel free to follow along. Bring up Cursor while um I'm sharing my screen, and hopefully this will, you know, become second nature to you all as you guys incorporate Datadog more and more in your Cursor workflows. I'm going to go ahead and share my screen, and I'm going to start by introducing the Datadog plugin within

11:01 Cursor. So, a very common question we get within Cursor um and just to confirm, Tib, everyone can see my screen okay? Or you can see my screen okay? Perfect. Um the plugin for Datadog within Cursor uh and a common question we get is what is the difference between a plugin and an MCP is simply a packaged version of the Datadog MCP with a set of skills, sub agents, and hooks that that vendor might uh apply. So, an example is if I actually go to the Cursor marketplace

11:32 and I go to the Datadog plugin, you'll see that the Datadog MCP is right here along with a set of skills that the Datadog team themselves have published. Um the reason that we kind of have plugins and what we like about them is it's a way for these third-party vendors like Datadog to allow users within Cursor to make the most of the product. So, now that I use Datadog within Cursor, I not only just get the MCP, I also get the set of skills, and I can

11:59 actually click into them here and actually see what's in each skill if I want. Cursor has this wonderful built-in browser that's really great for that. Um what's cool about this again is I can choose whether or not to use the skills if I don't want to. I can always just incorporate just the Datadog MCP, but I would highly recommend actually installing the plugin. You can see I already have it installed, but you would see an install button here if you

12:22 haven't. Um and you can apply it just for yourself if you want it to be, you know, all for all your projects on your account, or you can add it to your current project if you want it to be project-based as well. So, up to you and how you want to apply the Datadog plugin in here.

12:36 I'm going to go ahead and close this, and I'm going to do two things. I'm going to run um a Datadog agent how I would normally in my workflow. Um and I'll show you all what that looks like. And then I'm actually going to use a feature called canvas within Cursor. So, if you haven't heard about it yet, it's actually a very cool new feature that we're using. And we're actually going to use canvas to take Datadog uh data and present it really nicely.

13:01 So, I'm going to start by opening up a new agent, and I'm going to do what I do, you know, almost every day, which is I'm actually going to help uh diagnose an issue for a customer. So, I'm going to say um customer with team ID 5997694 um is having some issues with their agents window. Can you use the Datadog MCP to diagnose the issue, look at some logs, and let me know what you find.

13:38 So, often times I do this when I get, you know, a DM or a message from a customer saying, "Hey, you know, I'm not able to see X or Y." Um and what's really cool is, you know, our logging is really robust within Cursor, and so we automatically go and check the logs in Datadog, and I don't have to, you know, look through any dashboards, I don't have to go to the Datadog. I can just do all of this investigation within Cursor, which is really neat. Um so, I'll have

14:01 this run. In the meantime, I'm going to run another agent um and do a little more of maybe an internal use case that you all might find useful. Um so, this is actually where I'm going to use canvas, and I'll show you all what that looks like. Um and I'm going to say here um I want to see what the most common customer errors are with the Cursor agents window. By the way, when I say agents window, I'm actually just referring to this window right now. Um this is called the agents

14:30 window. It's uh a new interface that we released about 3 weeks ago. Um it looks very agent forward um and it's actually a great way to interact with Cursor. If you ever want to go back to the editor window, you can do that here, but I've been spending most of my time in the agents window.

14:44 Um help me visualize this with canvas. Just new {slash} canvas here. This is a built-in skill. You all should be able to see it. Um and um make it so that it is clear enough that I can present it to engineering leadership. I'm going to use Composer 2 fast here. I love this model and even or especially for Datadog uh MCP work, I think it's really good. This is a model that has been trained on code and reading and writing code, debugging code, so it's

15:19 very, very good at those things. Um so, I highly recommend trying out Composer 2 with Datadog um and in the agents window, it is a really, really fast way to actually look at all your logs. Um since I want to see both of these agents running simultaneously, I'm going to do something cool. I'm actually going to do something called tiling with an agents window, and it's very straightforward.

15:39 I'm actually going to take this guy and just put him side by side right here. And here we go. Now I have both of my agents running. Um I have one about my customer that I, you know, was having some issues with their agents window, and as you can see, it's looking through the logs, getting some metrics. Um I can, you know, expand any of these and see what's going on there. Um and then I also have this one running here, which is going to create a leadership-ready canvas for me. So, again, two different ways to use

16:05 Datadog, one internally, one externally, um but both really, really robust and powerful in the way that they can use it. Um as you can see, this canvas is ready, testament to how fast Composer 2 is. I'm actually going to go ahead and make some real estate so that we can see it. Um so, let me actually close this agent for now um so we can see the canvas in its full glory. Um and there we go. Here we see some uh you know, some visualization of what the errors are and what I can present to

16:35 leadership. Um canvas, as uh I kind of briefly mentioned, is a new feature in Cursor that acts as a form of enriched UI. So, instead of, you know, doing markdown files all the time, you can use canvases for anything. Um some examples that we have are Actually, let me open the the template right here. Are you can make like a PR review canvas, you can do a docs canvas. Uh we often times do like dashboard health canvases or anything like this where you maybe you need to

17:03 present something to leadership, and you want, you know, something that's a little bit better than a markdown file. Um this is just automatically created for you based on data that it sees in Datadog, which is really neat. Um so, definitely try the Datadog MCP with the Cursor canvas. I think you'll be really happy with what you find. Um I'm going to quickly go back here. As you can see, I saw that little unread agent, meaning that maybe this guy is ready. Looks like

17:26 it's doing a little bit more searching. That's totally fine. Um it's obviously looking at a lot of things for a user team ID. Um and I also kind of, you know, made up this issue, so it might not see anything. Um but I just wanted you to see how you can actually use a uh real customer in Datadog to find logs and to get uh you know, a summary of things that are wrong. Um I'm actually going to come back to this um and move over to cloud agents. Are there any

17:50 questions in the meantime that I can answer? Oh, yes. I'm seeing that folks maybe are unfamiliar with the agents window. Um I can show that really quick how to get here. Um if you're not seeing this interface, you're probably seeing a different one, which is the editor window. I'm going to go ahead and show folks what that is. This is probably what you see before. Um if you see this agents window at the top, that's usually how you get to this interface right here. Um but if you don't see that, you

18:18 can always do command shift P and switch to agents window, and that's how you get to this brand new spanking UI interface here. Cool. Do one last look at the chat. Um folks are asking about sharing canvas. This is actually another feature that's coming very soon. Um we are aware that people love it and are wanting to, you know, share this, download it. What I would recommend right now is based on what you use for your documentation, whether that's Confluence, Notion, you can always publish it there. You can

18:48 always check it into your GitHub repo. Um we would eventually have a way to easily share it among Cursor users, uh but for now, that's probably the best way to to use canvas. All right. Um I'm now going to switch gears and talk about Datadog in the cloud. Um and you'll see a bit of a similar interface, but you'll also see some cool things that Tib mentioned earlier in terms of setting triggers and alerts that can actually make the most out of Datadog in an automated setting.

19:19 I'm going to go ahead and minimize this, and I'm going to go and open my Chrome. Sorry, the Zoom bar is blocking. Here we go. Okay. So, I'm going to start by showing the cloud agent interface within Cursor. So, if you go to cursor.com/agents, this is the main interface or portal for cloud agents.

19:41 Um if you see uh something that looks like this, chances are you have cloud agents turned on already. If you don't, you'll probably see a button that says connect GitHub, and that means you need to set set a repository. Cloud agents are agents that run asynchronously or on a remote VM.

19:55 Meaning, I can send off an agent and I can shut my laptop and those agents will continue running with no problem because they're not running on my machine. Um, people often ask, why would I do this? Um, one is just, you know, it allows you to have agents running without you constantly monitoring them or constantly having your laptop open. For folks with, you know, old laptops or laptops with a very small amount of, you know, uh, restricted constraints there, um, cloud

20:21 agents are great so that it's not running on your machine and hampering your laptop. Um, and then one actually feature that someone uh, told me who lives in a very distributed company is that it's great to work across different time zones. So, you can send off a cloud agent, have it do work, you know, at 3:00 a.m., 4:00 a.m. while you're sleeping and then your teammate who is in Asia or Europe or whatever can pick off where your cloud agent left off and

20:42 go ahead and make changes. Um, and so that's why people love cloud agents is because they operate at any time of day, um, however long they take until they finish. Um, a little bit about cloud agents in Cursor. This again is the main interface, but you can also launch cloud agents from Slack, you can launch them from Linear, um, you can launch them from GitHub. Um, there's many different ways to launch cloud agents and what's cool about cloud agents is that they have access to MCPs. So, as you can see

21:08 here, I have the DataDog MCP enabled in the cloud, um, meaning that I can access all my logs, I can access all my skills, um, related to DataDog here, which is really awesome. I'm going to start by showing you all, um, what I would do with a cloud agent at DataDog, um, specifically with regards to automations. So, as I mentioned, cloud agents are agents that can run asynchronously, um, on a remote VM.

21:34 Automations in Cursor are scheduled or event-triggered cloud agents. So, basically, these are agents that depend on some sort of event happening in order for them to run. So, you might have thought of this automatically when I said that. You could eventually or actually right now I'm going to show you, uh, schedule a cloud agent based on a DataDog trigger. Um, and I'll show that in a second. I first want to show generally automations, uh, in Cursor. There's a lot of different templates

22:03 that you can use and build off of. So, if I, you know, click one of these, I can go ahead and start building and it'll give me like a template to work off of. But for today's automation, I'm actually going to create one with you from scratch and then show you an automation that I have built already with the DataDog trigger implemented. So, in an automation, again as I mentioned, you can schedule a trigger. Um, so it can be time-based, it can be based on GitHub, GitLab, uh, it can be based on Slack. So, a very common one

22:31 um, is, you know, let's say you have a DataDog alerts channel in Slack. You can say, "Hey, once there's a new message in that DataDog alerts channel, I want you to" and I'll go ahead and add the DataDog MCP here. Pretty straightforward, just go ahead and Oh, actually, I think I already have it set up. Where are you? There you are. Um, as you can see, it's connected. Um, if you need to authenticate, I'll tell you to authenticate here. Um, and I can say, so let's just do an example here. Let's say

22:58 new message in I'd have to select a repo and connect it, but I would say new message in like my DataDog alerts channel and I would say, um, "Figure out what the message is saying from Slack and use the DataDog MCP to uh, interpret any dashboards or uh, spikes in errors that are coming from the alert, investigate any related code that could have changed this in the code base." Um, and so this is a great example of what an automation could look like here. I'll rename this to like DataDog Slack

23:40 alert uh, automation. So, I'll have a new message that occurs in a channel. I'll have an instruction that says use the DataDog MCP to inspect it. It would do exactly what you saw uh, locally where DataDog everything will run, it'll look at logs, it'll look at monitors, it'll look at errors. Um, and then I can go ahead and ask it to even, you know, put up a PR or maybe send a message to Slack being being like, "Hey, this is what I found so far." Um, so very cool uh, way to kind of start from

24:07 uh, you know, a DataDog alert in a Slack channel. You can also set up a alert specifically from DataDog itself. So, I'm going to do that with you all, um, and then I'll show you what that looks like in uh, you know, previously made automation. So, in uh, Cursor, um, in the automations, I'm actually going to go I think I have it already up here. There we go. Um, I have this automation that is actually triggered by a webhook. And the way to do that is you actually when you create a new automation, uh, you can scroll

24:37 down past GitHub, GitLab, past Slack, all the way to webhook. And this makes it so that you can really wire up anything. Um, so what it'll do is it'll actually give you once you've saved the automation, it'll give you a URL and an off header. And what I actually did is I went to the DataDog integrations. Um, so integrations are actually I think down here, um, and then I go to the webhook section right here.

25:01 Um, and then as you can see, I have two kind of automations. This is the one that Nate made that I'm showing, um, that has a URL which I get again from the automation. So, it's triggered right here, um, and then I get an off header that I'm obviously not going to show, um, but once you've set that up within DataDog, um, you can now have this webhook uh, be wired up. And so this is a very simple but very powerful automation that we have within DataDog, which is this webhook contains details about an error

25:29 from DataDog, triage the issue and open a pull request with a fix. You can use the DataDog MCP to inspect logs, look through Git blame and history, find the commit PR that caused the bug. Um, so what's great about this, right, is that no longer do you have to page someone at 2:00 a.m., you can actually have this automation trigger do most of the work because the DataDog MCP is so powerful and so good at what it does. Um, so I'll actually do a live run with you all. Um,

25:55 I have a sample JSON payload from when this um, this this automation was fired earlier. So, I'm going to go ahead and do a test run and so you all can see what this looks like. So, in an automation, once you've created it, so this is pretty straightforward, you can do a test run and for something that requires a webhook payload, you can go ahead and just copy and paste that.

26:17 So, I'm going to go ahead and put that here. Um, no extra context needed I think. This is just all it needs. I'm going to go ahead and hit run test. And as I mentioned, automations are cloud agents under the hood. So, if I go ahead and just click on this test run, you'll see that it looks exactly like what a cloud agent usually looks like, which is it'll set up your environment for you. Um, it'll get all the details, um, and then it'll go ahead and start

26:42 running and looking up DataDog in um, you know, issues in your code base. Um, a quick plug on the model I'm using here. So, again for cloud agents, you get your pick of the model. I actually tend to use Codex 53 in Composer 2, mainly because those models are so good again at code reading and writing and they're so inexpensive, um, that I feel like Cursor cloud agents do a really good job with both the token usage as well as uh, with uh, the output of what

27:10 it does. Um, so we'll see this run. I'll show you all, um, as you can see, it automatically converted my automation payload and says this webhook contains details about an error from DataDog. It's going to triage the issue and open a pull request with the fix, um, and it's going to use the DataDog MCP to inspect logs here. Um, as you can see, this is Cursor actually launching, um, a skill. Um, so this skill Oh, actually, I I don't think it's doing anymore. Um,

27:36 but we actually have a skill within Cursor. So, let me go ahead and show that uh, in our uh, Oh, not that, sorry. Um, in our local uh, code base. Um, Cursor has a really cool skill that we built Oops, on top of the DataDog MCP, which I highly recommend. We we call it just using the DataDog MCP skill. As I showed earlier, DataDog has their own set of skills that they published with the plugin, but I think it's really cool and important to create skills on top of how

28:07 your team uses DataDog. So, Cursor uses DataDog extensively, so we have, you know, different ways of like, "Hey, these are the tools. This is how you should use them." Um, you know, it's automatically telling users like if the DataDog is not available, tell the user to check the status. Um, and so this these are important for you all to kind of build on top of your additional MCPs because the more skills you have around how you guys use DataDog with Cursor,

28:32 uh, the better and more kind of um, I guess like pointed it will be in finding the issue. So, this is just a quick plug that skills are important. Cloud agents can use skills as long as they're in the same repository, um, so definitely just keep your skills related to DataDog in your .cursor folder and the cloud agent will be able to read from that.

28:52 I'm going to go back now to the web so you all can see it working. There you go. Um, this is it using the MCP, so it's using the search DataDog monitors that Tib showed earlier, which is awesome. Um, it's able to find particular things. Um, it found some a key code path that, you know, maybe could have caused the issue. Um, so this is an example of, you know, how you can do a really good integration with DataDog like this. Um, and then once it's done, it'll actually we can actually see a sample run here. Um,

29:21 it'll put up a PR for me. So, I can go down here and see uh, the changes that it's made. I can go ahead and see what fix it's done, um, and then I can mark that PR as ready, um, and then have someone review it. So, it really goes from like alert to PR all in one go automatically. There's nothing I need to do. Um, as always with cloud agents, I can always add follow-ups if I want, but cloud agents and automations are meant to be things that happen either on a schedule or on a trigger. So, we

29:50 actually like the fact that it's kind of running autonomously here. Cool. Um, I'm going to stop and quickly check for questions. Um, Awesome. Um, I can see what skills I can share. Uh, looks like Adithya and Lucas are getting most of the questions. Um, question, can we connect self-hosted GitLab to agents? Um, yes, you can. Um, cloud agents do use self-hosted GitLab.

30:17 So, by all means, if you ever want to check your cloud agent settings, you can go to cursor.com/dashboard and you can go to cloud agents here, um, and you can see the full list of environments that you have set up. Again, self-hosted if you want to do that. And then, um, if you need to integrate with GitHub or GitLab, that is under integrations in MCP, um, and you can see here you can integrate with all the things in addition to like PagerDuty, Sentry, and hopefully DataDog will actually come here very, very soon.

30:45 Um, but yes, I will stop there. Um, I know we have about 10 or so minutes left for questions. Um, Adithya or Tib, is there anything that you guys would like me to cover or I can talk about in more detail? Nothing for me. Maybe we can open up to to more questions from the audience and and show them stuff they want to see. Yeah. As well.

31:16 Cool. Um, Fotis is asking, can we analyze web performance data from DataDog? Yeah, so we can actually see dashboards from from Cursor with DataDog. Let me actually go ahead and show that. Going to open up Cursor, uh, one more time. I'm going to open up nightly here. Um, and I'm actually going to see, uh, in every sphere, I'm just going to say, give me the top, uh, five worst or, you know, most latent endpoints uh, in our codebase, including their dashboards,

31:51 uh, and I'll just say use the DataDog. Oops, use the DataDog MCP here. Um, so you can always interact with, uh, dashboards from DataDog if you want. Um, they should actually show up here, um, which would be really, really useful. Um, you can see like you can look at spans or look at dashboards from here. Um, you can even create DataDog dashboards from here as well, uh, which is really great. So, sometimes that is also useful when you want to go from Cursor back to DataDog. Um, I'll go

32:20 ahead and see how it does in terms of showing the dashboards. Looks like it's searching through them right now. Um, but in the I see, oh, can you interact with the BITS investigation via the MCP? I don't know, actually. I have not tried that. Tib, do you know if that's the case? I don't think so. >> Yes, yes.

32:37 Oh, I mean, that's cool. >> Um, so it depends on the product, but like on error tracking, we return the investigation I was showing. So, >> Okay. this partnership between Cursor and DataDog really happens here. Like we do the runtime investigation and then hand off to Cursor for the remaining part of the RCA and then the code fix. And yeah, games B tools return that.

32:57 Cool. Yeah, that's awesome. Um, and then, just so cuz I think a lot of support or a lot of questions are coming about canvas. To launch a canvas within Cursor, um, there's multiple ways. The easiest one is just doing {slash} canvas and Cursor will automatically know that you want to do a canvas. Um, another way is if you open up this side panel and hit button, you should see canvas there.

33:19 And then these are kind of some, you know, canvases you have existing or you can just do create new canvas. And I'll just, you know, do the {slash} command for you. But {slash} command is usually the best way. You can also use any of these canvas skills that exist already and you can add them to your marketplace.

33:37 Awesome. Um, it'd be great if the DataDog MCP could build out a notebook in DataDog. Um, Is that coming? >> That's coming. Okay. It is coming. Uh, we're already working on a lot of, um, write tools, right? We've focused on read-only tools to start, but now moving to the right part, uh, and some of them are already available. I think I answered a question a bit, um, earlier about, uh, dashboards. Um, notebooks, so you can create dashboards using the DataDog MCP. You cannot create notebooks yet,

34:09 uh, but internally we are trying this tool and I'm actually using every day. It's very, very useful. So, it's about to come. We just need to stabilize it a little bit further. Sweet. Um, great question. When should I use the BITS AI dev versus having Cursor do its investigation investigation with the DataDog MCP?

34:30 That's a great question. Um, it really depends on your flow. I think there are some very interesting, um, situations when you want DataDog to do the entire flow from end to end, uh, but in my experience and what I see with customers is that customers love and users love, you know, um, having something that's more hybrid and tailored to their workflows and I think this is where, you know, Cursor automations are particularly powerful.

34:57 You can connect, you know, different tools. For instance, like, I don't know, Linear if you want to create a ticket, you can create a connect Slack and so on. Um, and this allows you to do something that I think is more, um, yeah, customized to your workflows. And I've also, you know, mentioned a little bit the I think the partnership between, uh, the DataDog investigations and then, um, Cursor, uh, looking at the code, investigating, and generating the code fix. And I think this is the sweet spot

35:28 when it comes to the handoff. But again, it can happen at any time. You can only focus on Cursor for the entire investigation and and generating the code fix, um, do something that's kind of half-half between DataDog and Cursor. I think again, this is the best situation. Or you can have DataDog do everything. It's um, a lot of options here. Yeah, I will say also, uh, based on my personal experience, I often use BITS for, uh, just understanding like how to

35:54 use DataDog for certain things. Like for example, I'm not a DataDog power user. I've used it, but I'm not, I would say, particularly advanced in it. So, I actually used BITS yesterday to test out the webhook integration and make sure that worked and it actually walked me through those steps. So, I would say BITS is really good at, uh, obviously, you know, understanding your code, but also understanding how best to use DataDog and like, hey, I want to create

36:15 this monitor using, you know, these, you know, particular constraints or restrictions, whereas Cursor is a little bit more like you can interact with your customer data, you can interact with your data. Um, so it feels a little bit more like a full ecosystem. Um, BITS is great for just like working within DataDog if you want to do any DataDog specific things.

36:35 Exactly. Oh, this is a nice question. Can I show my favorite Cursor thing that people don't use much? I would love to hear, Tib, if you have any thoughts here as well. Um, I would say canvas, honestly, uh, is a pretty, uh, big one for me. I think it's really cool. Um, I've just played so much with it. I've come up with like full slides, customer guides, uh, you know, just uh, you can really go full wall-to-wall with canvas. Um, and then another feature that I think is

37:05 really great in Cursor, obviously, is automations, um, >> [clears throat] >> but specifically, automations that happen on a schedule. Um, so we've been seeing this, um, and I'll show just exactly like my favorite automation that I have. Um, you can even have this hook up with DataDog. I think we have one here. Yeah, investigate top DataDog errors. Um, so this one just, you know, looks at DataDog and looks at your top errors, focus specifically on that, and then

37:31 puts up a PR. Um, this is a very common automation. It's in our template builder. So, if you want to just get started really quick, uh, this one happens every day at 5:00 p.m., um, and looks at your top errors, sees what's going on there. Um, but I think automations that happen on scheduled times are really cool. It's off It's like very easy to wire up cron jobs, basically, which I think is really awesome.

37:53 Yeah. You You used to do the example I had in mind. Uh, my my, uh, daily driver right now is making sure I set up a lot of, um, cron jobs and automations on, well, PM related tasks, but like stuff about, um, you know, parse, um, events that happen in Slack, in my calendar, in documents, and making sure you can actually digest all of that and send summaries. Um, and when it comes to DataDog, one thing that I love doing as a PM is like trying to understand, you know, how users behaved on, uh, a given, um,

38:26 on a given page, on a given feature. Uh, and so what I have set up as a cron job is also to send me reports of, um, metrics and, um, analytics on a given flow. And that's something that's proven very useful instead of, you know, uh, coming to DataDog every day and it's like, okay, what happened yesterday? I need to compare and actually think about going there. I just need to, uh, I can actually forget about it and have Cursor send the digest every

38:53 morning. That's awesome. I love that. I think it's a great feature. Um, one thing I want to say that, uh, I think has come up in the chat a couple times is like, what about other integrations? Um, you can chain on as many integrations as you want both within Cursor locally as well as with cloud agents.

39:10 So, for example, if I go here and I said my top latent endpoints, gave me some here. Cool, that's fine. I don't know how accurate this is, but that's okay, um, just because I'm using a demo repository here. Um, and then I can say, uh, okay, based on these, uh, you know, top, oops, these top errors, um, can you create, uh, Jira tickets for me with, uh, solutions or maybe strategies on how to tackle each one. Um, and so this is like a very common workflow uh at Cursor, which is we use Data Dog, we identify errors, we see,

39:48 you know, where our gaps are, and then we create linear tickets in Cursor, not instead of Jira, um and then have uh you know, those tickets live, and then, you know, we either assign those tickets to a cloud agent, and each agent works on each ticket. Um Let me go ahead and make sure that my MCP is enabled with Datadog. It looks like I have to connect. Go ahead and do that. By the way, this is how you would connect with um the Datadog MCP. Um just so you all see

40:12 the authentication process. It's very seamless within Cursor, which is awesome. Um there's no like back and forth, there's no off issues. It's it's just like very straightforward. It exchanges the tokens, and now it's ready. And I can go ahead and say Datadog MCP enabled.

40:28 Um and then now what it should do is it should take kind of those strategies that it's given me earlier, and go ahead and make tickets based on that. So, there's a ton of different integrations you can do within Cursor um that really kind of build on top of uh the Datadog extension.

40:43 Hey, I'm Neda. Can you show people how to hand off tasks from local to cloud with like the slash local or cloud commands? Yeah. Um so there's multiple ways you can do that. The first is you can actually say move to cloud just by right clicking the agent here, and then that will automatically send this to the cloud. So, it's a including committed changes, that's fine. It'll include some changes here, and then it'll go ahead and actually send this up to the cloud

41:07 once it's done integrating with the MCP. So, that's one way to do it. Um you could also do, again, I think like slash local is one of them where you can bring it down from the cloud to local, or you can actually just do it right here and choose whether you want to work on the Mac versus the cloud. Um but the agents window is meant to be this like seamless flow from local to cloud back to local.

41:29 Um oh, looks like it had some issues, that's okay. Um but yeah, you can always just right click and hit move to cloud whenever you want if you want to go back and forth. Um the one thing I will say uh from agents window is this is super seamless, and it's great to do. Um what I'd recommend though for cloud work, especially automations work, is I'd actually recommend starting in the web, and then if you want to do more work, pulling it down. Mainly because when you're in the

41:54 web, um you can see all the agents that are also cloud agents. Um in locally in the local agent, it's a mix of cloud and local. You could actually, you know, organize them and have them be it so that all your cloud agents are up here, all your local agents are over here, and you can organize it however you want.

42:11 But I like doing stuff in the web because this just kind of consolidates all my cloud agents together here. Awesome. I know we have a couple minutes left. Um Josh is saying, "Be great with the webhook automation to be able to have the right angle to find the right repo." That's actually coming really soon. We have uh Aditya answered it. We have a multi-repo uh feature that's coming up um that can really help with this. Um we're also going to be looking at um

42:38 automations without repos, that should be coming soon as well. So, if you want an automation that's simply like uh hey, like look at the Datadog alert, and then immediately message someone, or look at the Datadog alert, and then immediately, you know, post it to my Slack channel. Um that will be coming as well, and that actually doesn't require uh a GitHub repo at all times.

42:59 Cool. I see there's one question, which is to troubleshoot a customer's issue using MCP since we need to for some form of access to their environment, such as an API key or application key. Um this is where I would actually recommend using skills, Harshita. Um having a skill that lives on top of your Datadog Cursor integration will actually allow you um to basically say like, "Hey, when you diagnose customer issues in our codebase, these are the ways you

43:22 go about it." And if you need to give any API keys or any, you know, specific instructions to the agent, you can do that in the skill, so that lives on top of your Datadog Cursor integration. Uh Jira ticket cannot be a trigger just yet. Um the current triggers that we have right now are time, GitHub, GitLab, Slack, Linear, PagerDuty, and Sentry. Um you can make it a trigger using the webhook custom webhook. In fact, I have a teammate who has one where he has a Jira trigger uh based on a webhook of

43:54 moving his ticket from to do to in progress. So, you can custom that yourself, just like what I did with Datadog, but hopefully that should be coming very soon. All right, I think we are at time. Awesome. I hope everyone learned something new. Uh thank you so much to the Datadog team for setting this up. Um and thank you Aditya for and Aditya and Ankit, both of you for uh for helping out in the chat. Thank you. That was really fun.

44:25 Bye, everybody.