Monitoring & Error Tracking in Serverless Functions

Captions provided by White Coat Captioning (https://whitecoatcaptioning.com/). Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.

Hello, everyone, and welcome to another episode of Learn With Jason. Today on show, we're bringing in Ben Vinegar. Ben, thank you so much for hanging out with us today. How are you doing?

I'm doing okay. Hey, Jason.

I'm super excited to have you here. I think this is going to be a lot of fun. We're talking about something that I think people maybe get a little squeamish about which is what I'm excited about because it doesn't have to be something to worry about you. Before we talk about that, I want to talk about you. Ben, for folks who haven't heard of you before, do you want to give us a bit of a background?

Yeah. I'll keep it brief. Just a long 20-minute story.

Hey, this your show, if you want to monologue, you can.

Yeah, I don't know. Let's see. I got my career started maybe 15, 16 years ago in graphics, driver development, pivoted into web, decided to become a JavaScript specialist. I worked for a company called Discuss. Still around. And from a lot of the things that I learned there, co-author of a book Called "Third-party JavaScript" which was published back in 2013, which is like a millennia ago. I joined a company called Sentry. I was employee number four to really kind of Kickstart JavaScript error collection. Sentry is an error monitoring product, we're going to talk about here. And also do some UI development. And today I'm one of our VPs of engineering. I manage a big team of people building a Sentry product, making it better, helping everybody, you know, collect errors, monitor the performance of their application and production.

Very, very cool. So Sentry is something that I feel like we see Sentry around, like, you're very good as a company at sponsoring conferences and being visible in the community, but I think a lot folks are still kind of nervous about things like error collection. I think that when we start thinking about that, you -- there's a thing in the back of my brain that goes, oh, yeah, that's a thing when you become a big company. So if you don't feel like a big company you think, well, maybe I don't have the resources to do that, right? This is something that I think is really interesting about Sentry because Sentry's whole game is that it shouldn't be. So, can you talk a little bit about, like, what is the I guess the reason that Sentry came to be? Like, what's the space that Sentry is filling?

I mean, the origin of Sentry, a lot of people don't know it's an open-source project originally. The first commit was made in 2008. It was actually called JengoDb log. It was a plug-in for Jengo. History time. Jengo had a feature whenever there was a crash, it could email you.

Oh, I didn't know that.

I don't know if this exists today, but in 2008, I'm told that it did, and users of Jengo were hit with this problem, people hit a bunch of errors, you'd spam your own inbox.

Mm-hmm.

So, David Kramer who is, you know, the founder of Sentry, the open-source project, and the company, basically created JengoDB error log a way to aggregate similar errors so you only got emailed once for kind of like a distinct problem, right? So if 100 people go and hit the same crash, you'd only get one email. If they went and hit some other page and hit a crash, you'd get a different email. It made sense, these errors that were happening in production. So, that's the origin. And, you know, from there, it's kind of taken off. You know, went from being a plug-in to its own standalone server. Went from being for Jengo and Python to -- thank you for subscribing.

I love that. Usually I'm the one who does that. That's wonderful.

Always wanted to do it. Okay. So, watch too much Twitch. You know, so, then from there, you know, became sort of like a generic error reporting endpoint that, you know, whether you're doing Ruby, Node, browser JavaScript, pretty much every platform today we ingest that. It's a dashboard UI. Still get emailed if something's wrong.

Yeah.

So I went into story time the origin of the project and the company.

No, but I think that's interesting. So, I mean, you know, the thing that I think is really interesting about this, right, is, like, if we don't do this kind of error collection and getting notified if there are errors in production, then there is really no way to know when something is wrong, outside of getting emailed by a customer or tagged on Twitter, right?

Mm-hmm.

And so that -- and, like, I just had that happen recently where I launched a new episode, and then IED Ted the -- edited the URL, and the tweet queued up didn't get uploaded. People were in my DMs saying, hey, your site's broken, and I'm panicking, right? If I had some kind of error threshold in there it says, hey, you're getting 404s, I could have fixed that immediately as opposed waiting until the next time I checked Twitter. And also it's kind of embarrassing when, like, a bunch of people are all saying, hey, your website's broken.

Yeah, I mean, I think that still a majority of the industry still relies on traditional kind of like, you know, support escalation of problems.

Mm-hmm.

And that's pretty slow. I mean, listen, Twitter, that's pretty fast, you know?

Right. Yeah. Short feedback loop.

It's one of the faster feedback loops, so that's not so bad, but for many people who work at software companies, even small companies, you know, email goes in, hits the support team. People are like, whoa, is this real or not? They try to reproduce it. Hey, I can't reproduce it. This never happened. Delete. So many things like that happen. And to just get informed right away with, you know, what Sentry provides you is some diagnostic tools, Stack trace, bread crumb trail of what happened. A lot of stuff you may have to go shake down the user to put yourself in their shoes and understand what they were doing. Just gets you there a lot faster.

That's actually a really good point. When I use something like Sentry, I'm just getting, hey, you have an error, I'm getting this error happened and this is the operating system and the browser that it happened in, and this is the line of code where it happened. You're sending me all of that information, right? I don't have to go back to my users or open up my browser and try to reproduce because I have all the information right in the reporting.

Yeah. I mean, I certainly remind -- remember working in a time when it was like, hello, user, can you open up developer tools, can you take a screenshot of the console and send that to me please?

Yes. Absolutely.

And I think that's still going on, right? Your comment about, like, a lot of people don't do this. I think that's real. You mentioned the conference circuit. One of the fun things working for I guess a previously small company is I attended a lot of those conferences and I'd ask people all the time, how do you get told when something is wrong? And I'm always surprised that, yeah, for the majority of people, I get an email or even the telephone call. There are people who are still getting, you know, picking up the phone.

Yeah, yeah. That's -- so that -- like, I'm pretty excited about this because, you know, I thought what we could do today that would be fun is we could walk through the process of instrumenting a real site. Because I feel like that's what most people are going to be doing. They're going to be trying to introduce this into code that already exists. You know, most of the time, we're not doing net new. So I have a -- I thought we could use just the Learn With Jason site, which, you know, it will save me from further Twitter embarrassment when I break my own site, and then I'll know about it from the robots instead of people who are disappointed in me, and I'm going to just rely on the fact that the robots haven't achieved the ability to feel disappointment yet to spare me shame.

I think we have some marketing copy in there that makes you feel bad.

I look forward to Sentry shaming me in my inbox. Okay. So, if we're going to do that, I'm going to switch over into pair programming view here. And before we get started, let's do a quick shout-out to the sponsors. We have Jordan doing live captioning with us today. Thank you so much, Jordan. Jordan's here from White Coat Captioning. And that is to make the show as accessible as possible. If you need the live captions, they are available right on the homepage, learnwithjason.dev. We have Netlify, fauna, Auth0 and Hasura all kicking in to make the show more accessible and that means a lot to me. So make sure you check them out. Also while you're checking things out, go follow Ben on Twitter. He is tweeting all sorts of things. I see this hot take. I enjoy that. I also immediately upon doing that went and look at your website. I was like, ooh, I got to see this HTML page website. Nice and clean. Liked it. Loaded fast. It's great.

Single files can be very fast. This is true.

Here is the site. It's nice and quick. Go check it out. Go inspect the source. It's one of the first websites I've seen in a long time where you can actually inspect the source and it's, like, intelligible. So that's nice. We're here to talk about Sentry. Sentry is here. I won't charge you the ad bucks.

Thank you.

So, we can go check out Sentry. If I want to get started with Sentry, so I'm going to just do this inside the Learn With Jason site, right? So, I have my code base here, and I'm on the main branch. Let me make sure I've pulled all the latest changes, in case I change anything. All right. We're good. So, this is the production code. I have no real changes going on here. And I'm going to check out a branch so that we can reference this. And we're going to call this feature add Sentry. Okay. So now I've got a branch. I'm on the the Sentry site and I'm ready to rock and roll. What should I do first?

You can try Sentry for free. We give -- we have a I think pretty generous free plan that is, you know, track so many errors, get informed for your inbox and don't have to pay. Give it a shot.

Okay. So let's do that. Probably not going to use that securely generated password. Let me pull this off screen so I can get another one. Give me just one second to generate an actual password. Okay. Yeah, I'll give you my fingerprint. Calm down. Okay. I agree to the terms of service. Let me pull this back over now that I'm done with that part. And I'm going to create my account. Did it do it? There we go.

Jason read the terms of service ahead of this live stream.

I did. That was my reading for last night. Okay. So normally I would go through this onboarding, but since you're here, I'm going to use you as my onboarding.

No, no, no, no, no.

No?

Oh, no.

What have I done?

Hit the back button.

Listen, I would use this back button.

Okay. I'm ready. Ooh, that's beautiful.

Also, you know, outshout to DJCheezyP. He's responsible for some of the animations.

Oh, so we would have to add code.

Learn With Jason is using Preact. Issues I use the React version or the JavaScript version?

Preact is almost completely API compatible, right?

Almost completely API compatible.

Let's do it.

Let's give it a shot.

Let's live dangerously.

I'm ready. Okay. So I have these pieces. So let's do that. I'm going to drop this in. So we're installing the React package and the tracing package. So let me run that. And while we're doing that, let's read what happens next. So I'm going to import everything integrations. And then -- well, hold up. I don't have to do anything? Like, this is -- this is it?

Yeah, I mean, you just kind of blast that code in and stuff should happen. I'm not a Preact expert, though. Let's see what happens.

Okay. All right. That's kind of -- that's actually kind of incredible. Let's give this a shot. So I'm going over to my homepage here. Where do things happen in here? I've got my -- close all this stuff out. I have my public folder. Not that one. I have my source folder. Oh, God. I've forgotten how everything works.

Can I just say, this is a bold choice . File paths on the right. This is blowing my mind. I've never seen this.

So here's -- here's why. It's because I do this a lot, and I don't want my code to jump.

Show us the way. This is incredible.

I'll tell you what I've done that I've now forgotten how to do. Tony, you're in chat. Where's the -- where is my HTML file? Page wrapper. That's the one I'm looking for. Here we go. Okay, so this is -- so I'm basically I'm using Toast, which is like a Next or a Gatsby generator. I don't actually control the HTML file. I think what I have to do is put it in here. This is the outer wrapper of everything that gets included around.

That's probably a good place.

Yeah, I'm gonna give that a shot, and we'll see if it yells at me. I'm gonna start here. I'm pulling in Sentry and integrations. And then down here, I'm pulling in -- so this is, like, generated for me off my account?

Hey, what plug-in is doing that kind of file size calculation as you import? That's pretty cool.

It is called Import Cost, I think. Import Cost. This is a great -- like, I really like this one.

Yeah, that's awesome.

It reminds me if I've made a huge mistake when I -- if I get in here and I'm like 4 megabytes, ooh, maybe destructure that one.

Mm-hmm.

So here I call this -- this, I assume, is generated with a public API key for me?

Yes.

So that it's going to my site.

Mm-hmm.

Pulls in integrations and browser tracing.

So this snippet, there is going to be extra stuff here, right? You noticed two packages. Standard error monitoring and also bringing in performance monitoring. So that's kind of what those two bits are about. The tracing is, you know, the library that we use for creating a trace, a performance trace of your code as it runs.

Cool. Okay. So, I've done this.

Mm-hmm.

And now I'm going to go back and finish the tutorial. Trace sample rate good. Any exceptions? So we can break it once we make sure this doesn't explode and all those things. Oh, waiting to receive the first event to continue. All right. So, let me start this, and we will do npm run. Got to actually -- man, I haven't run this site in so long that I forget what the command is.

So one thing if you're going to run this on local host --

Mm-hmm.

If it's possible to either build it somewhere on the web or, like, put a tunnel in front so that the -- it can be reachable via the internet.

Yeah, let's do it. I'll just publish it. And we'll get a pull request, and that way we'll have a URL. I'm building on Netlify, so it will take like a minute or two for this to be live. So then we can do pr create. And happy with that. We'll just skip a body because we know what's going on. We'll submit it. And let's open this thing up. Okay. So here's the code we've done so far, y'all. I have this sinking feeling this is going to be a really short episode. [ Laughter ] So, just validating what we've done here. We updated the lock file. We added the packages. And we add about ten lines of code, 15 lines of code. That's really cool. So now I'm going to go back --

I do want to make a comment. So it will certainly, like, work from local host, but the experience will be a little bit better if Sentry can actually reach your server because it will do things like if you're publishing source maps, which I believe you probably are, it will go and capture that to sort of augment the experience.

Oh, cool. I have no idea if I'm publishing source maps. I mean, I definitely have the curse of I build everything myself, which means everything is done poorly. So there is definitely a risk that this is not going to be the best example site.

I guess we'll find out. And also, I mean, it's also up to you, you know, source maps is if you wanted to publish all your source or not. Given the way that you operate things with that pull request, seems not unreasonable for you to publish, right? Not everyone wants to.

Yeah, I mean, it's definitely more of a I did whatever the default was. If my site generator is configured to do source maps, that's what I'm doing. I forgot I have light house audits on this. Come on now. There we go.

How fast is it?

Still pretty fast. I'm happy. Good. Got it going. And now we should have a live site. So, good deal. Let's go take a look at this. All right. So, I'm running -- no. What don't you want? What? Oh, no, this is -- this is a Toast thing, isn't it? I need to figure out why it doesn't want to import this. Okay. Okay. Okay. What you doing? So, maybe I need to do known entry points. How about that? Try that.

Maybe also the tracing went, too, because there are two. Yeah.

It was weird, it should have just found that. So I'm not sure why it didn't. I don't know, is -- I don't think Chris is in the chat today. Chris is the creator of Toast, and usually when I get myself into trouble with Toast.

Says make sure the post install does it.

Okay. That's a good call. Let's run the install and let's see what happens.

And let's just run it locally since we don't know if source maps are happening, and then we can --

Okay.

See what happens.

Yeah, we can totally do that. So, let's see what comes through. I get my Sentry React. Yeah, okay. So it looks like it's working now. And since we're there, I'm going to push this. All right. While we're waiting for that to build, I will run it locally, which means I'm going to run a build. And then I will start it.

What up, chat? Oh, hi, Chris. How are you doing? We were just talking about you. We're doing Toast things today. I'm putting Sentry into a Toast site, which I'm kind of excited about. My ears were ringing. Good. I'm glad I have that effect, still. I put it out into the universe, and the universe delivers. Okay, so we're building the site, and when it comes back -- there we go. All right. We're running locally. Now we've got our site. And it is doing the things that we want. Hooray. Okay. So now that we've got all of this going, I need to break the site, right?

Yeah.

Okay. Let's break it.

Should be easy for you. [ Laughter ]

I mean, clearly. It's barely holding together as is. We'll put something in the header that breaks. Let's do -- we'll put a call to -- call to something fake in here. And then we'll re-run this. And -- it should all go faster this time. \M Thank you, chat. No, what did you do? Are you yelling at me because I tried to do something with the -- come on.

It's hard to generate an error in 2021.

It really is.

So, what I recommend is this. Is doing something that, you know, oh, that -- which is more typical of what you would have in a production environment, right? So maybe like a string, you know, string access of a property that doesn't exist on an object is a good example of something that wouldn't be caught by Linter.

Okay. Okay. So that should absolutely fail, and the Linter shouldn't catch it, so let's try that one more time. These computers are getting too smart for their own good.

Yeah, I mean, it -- it is great that so many of these trivial problems are solved with tools. Maybe back in 2013, '14, I know people who used Coffee Script just for the compiler.

Mm-hmm.

Just to catch errors. Because they maybe weren't familiar with ES Lint or JS Lint at the time.

Yeah. I think that's a lot of the reason we're seeing people go in and to the typescript as well. That compiler is so nice to work with. So this should cause a failure. Yes, done. We have a failure. Which means if I go back to Sentry, event was received. Haha! Take me to my error. I like it. Okay. So now I have an error. No one likes product -- I like this. I like, you know, one thing that I definitely do appreciate about Sentry is you have such a personality with the brand. Like, I want to show really quickly before we go too deeply into this, I want to look at your blog because it's one that I -- wait, how do I look at your blog?

I think it's blog.Sentry.io. Or the marketing page can reach it.

There. Okay. Check this out. This is super fun because you get these, like, nice branded everything in here. Everything feels like it's part of the same website. There is a lot of personality here. Just, you know, I know that that's not what we're talking about at all, but, just like shout-out to your team for doing an excellent job of putting personality into something that could be so dry.

I think that's great. It is like a cultural thing that goes back to the early days. Chris Jennings, one of the company co-founders, you know, the Sentry website in 2015, the marketing slogan was shit happens. That was written there. I think it's been there for a long time. Hey, shout-out to Cameron, Hannah, Molly, Sammy. Oh, God, I'm forgetting folks. Yeah, they're great.

Awesome. I love it.

Drew. Sorry, drew.

Thank you for the bits. Thank you for everybody who is dropping boops. We are in good shape here, y'all. I appreciate you all. Oh, no, we're going. Are we -- level two on the hype train. Thank you, RubberduckDon. The only person I think I've seen complete a hype train is Cassidy Williams. I think level five is the highest you can go. So, you know, got to go for that high score, I guess. But anyways, let's keep talking about Sentry. So we've got this very charming tour. Do you want me to go through this or do you want to --

It takes, like, two seconds.

Okay. Let's do it. So, resolve issues. So this is like if I'm like, yeah, I meant to do that.

Or you've got a fix coming.

Okay. All right. Ignore. Yeah, I don't care. Identify your issues. So, this -- is this something that IED it? I edit. Any time an event happens with this error, it will resolve with this unique ID?

You see a user account to the side there.

Oh, my goodness. Thank you, DJ, for blowing it up in here. Ben and Zander that just got access to the boop emoji. I fully expect you to abuse this new power you have. Thank you so much. I've been working on a catch phrase. What do you think, welcome to the boop crew, mm? Good, bad, you tell me. We've got a unique idea for our error here.

Just got blitzed.

Oh, I love this so much. Okay. So, annoy the right people. That is beautiful. And we'll probably look at each of these individually a little bit here.

Yeah. I think we're hitting, like, a break point that is not super flattering. Can we widen this window just a teensy bit.

I'll do it. There we go. Look at all this stuff.

Oh, thank God.

All right. So, I have now widened the window. So we've got tags over here. That's really fun. We've got narrow down suspects. This is like a Stack trace.

Mm-hmm.

Wow, that's so cool. Retrace your steps. Oh, wow. Okay. Bread crumbs. Oh, man, I love this. Okay, so looking at this then, what we've done is we've now provided something where, like, I as a site builder can say if there are errors, like, if this error goes wrong, I know that it should be -- oh, whoa, this is not what I thought. Okay. Talk me through what this is.

This is some -- this is advanced mode. This is kind of like --

Okay.

If you're part of a big team.

Yeah.

You've got, you know, 50, 100 people using this.

Mm-hmm.

You can sort of create some routing capabilities. Not unlike GitHub code owners. So that certain people are informed or suggested, you know, based on Stack trace or URL or other things. So, you know, the right alerts are routed to the right people.

Yeah.

But it's kind of a power feature thing.

I mean, it is really, really cool, though,. Thinking through some of this stuff where, you know, you could have as a project rose, like, the header. Maybe the header is controlled by the design system team, and if errors come out of header, I as the site owner can't really do anything about it. Notifying me just means I have to relay that, but if I know where the errors come from, we can auto route. I love that. That's really, really powerful stuff. And the fact that -- and I could basically do, like, something like source components whatever, and then that would go to if I had a frontend team.

That's right.

That's so cool. This is really, really cool. Okay. And then I get to see my errors.

Meta, these are errors within the errors. This is about -- I mentioned it's trying to fine source mat.

And that's because there is a local host?

Yeah.

Got it.

And, you know, then we have instructions. You can upload source maps directly to Sentry. You can, you know, expose Sentry directly to source maps over if you want it it looked like some of the trace is pretty clean to me.

It's all ES Module so it ended up being pretty clean in general.

So it's certainly got something, but, you know, you see, like, function Z, function C, function A, right? Certainly something can benefit from source maps.

Yeah. And we can even see here, like, 41.9, so we can get down to 41.9 and, you know, I know where it is so I know what I'm looking for. Line 41.

If we actually get direct access to the source. It will actually show the source code in line in that Stack trace. Rather than just showing you.

Okay. Let's deploy this and we can keep going through some features. So let's do that. Oh, boy. Chris, more. More subs. Thank you very much for that. I appreciate it very much.

If this goes live, people can go and press that broken button as well.

Ooh, yeah, let's totally do that. We'll get everyone to the deploy preview here. Oh, my goodness. I'm really glad I turned down the notification sounds because it used to be that when this happened, we just had to sit and wait because it was so loud that nobody could hear us. This is wonderful. Yes. Welcome, everybody. Remember, you have access to emotes now. You can rain boops upon us. You can stampede Corgis across the screen. There are so many things you can do now that you are a member of the boop crew. Okay. So let's take a look. So, this is building. Which means that we can put this over here and take a look. We'll be able to see that progress up there. In the meantime, we can hang in here and this is -- so you auto tag things based on what we're using. So, like, we know we're in production, so I'm assuming I can set -- if I set, like, Node into something else, that would change this tag. Is that my assumption?

I believe so. Something to that effect. [�Corgi barking�]

Here we go with the stampede.

I think for every platform we try to grab as much auto valuable stuff as we can that's reasonable to ascertain. And, of course, you know, if you want to go deeper, there is sort of a -- there is a whole API for you to augment the data yourself. Right?

Got it.

You saw the bred -- bread crumb trail. You can add your own bread crumbs if you want. Baked in browser events, but if you know specific things about your application, you can throw those in as well.

For sure. Chat, if you want to contribute to our error Stack, go to this link. Make sure your browser is small enough so you see the open nav button. Click that and we'll get an error. We can see the error happening in the browser here. Wait, why are you doing that thing? Come on now. Oh, it must be Caching. So, let me clear the Cache and build again and we'll get real errors. I think it's just being -- it's being frustrating. Because if it's working locally, it will work here. It's all the same build process. We just got to make it actually do the thing it's supposed to do. So, we can watch this to make sure the build actually does what it wants. If it doesn't, we'll play with local and not stress about it because it's not an issue with Sentry, it's me not knowing how Preact works. So we're -- keep pushing this down.

I think the other piece, this may have happened off screen. If we've done this correctly, you should have gotten an email with the Stack trace embedded letting you know.

Let's see. I didn't confirm my email yet. So I just confirmed my email. Let me see if I have a Stack trace in here. I don't. It may not have sent it. Would it have sent if I didn't have my email confirmed yet?

I was playing around with this last night, and I think I experienced the same thing. So we're going to figure this out. Yeah, in a perfect world, yes. You can wire it up to Slack and a whole bunch of cool things. The whole idea is you land on that page, you're informed by that page as it happens, right? Like, that event was available pretty quick after you clicked the button, right? So imagine getting an email or a notification at the same time, then you avoid the turnaround time from a user.

And this is -- like, the Slack notification, I assume that's just, like, a button I click, right? So if I go in here, I can set up an alert, I would assume?

You can go into -- you kind of have to set up the integration. So you go into settings there, and you can kind of -- you got a whole bunch of cool things you can link this up to. Just a whole lot of that.

Yeah. Yeah. Very cool. And so, like, if I pick Slack, for example, it's going to have me authenticate with my Slack instance, but then I would be able to get, like, a notification channel. An error notification channel that would --

Yeah.

Like tag us if something is wrong. Or we can configure it to page our support team.

There is pager duty in here. You can have it go into an existing channel. Yeah.

Yeah. That's really -- I mean, this is really handy. Like, and there's a ton of these, too. Which is pretty awesome. Yeah, I like that. I like that a lot. So this is really slick. We'd be able to set it up with Slack and email and all those things. And also, like, Data Dog I know is what the Netlify team uses, for example. So being able to feed that stuff directly back into Data Dog would be handy for them. So then if I come in here, I can see my errors. This built for real this time. I hope. Let's try it. No Sentry errors. Okay. So let's try that. There we go. It broke. [�Echoed audio�]

Had the volume on in that tab apparently. Woof. Okay, that was fun. But it did what we wanted, right? We got our -- that scared the hell out of me. But now we've got errors. So if anybody wants to go and try this and click that button, you are going to be able to trigger some errors. And then we'll start to see those here, and probably I'll start getting emails, which is going to be really fun. But in the meantime --

Yeah, so it depends if --

There we go. There they are.

There you go. So, the grouping works. Basically it's a signature of kind of the Stack trace. But depending on how you build it and deploy it, it may create sort of a whole new signature, right? In the sense that if the build process is identical, it should be the same. Looks like this one --

Well, it looks like somebody in the chat is testing, too, because, like, somebody defined this to see what would happen. And so we get a different thing. So -- but this is really cool because, yeah, so now when we look in here, let me make this bigger again, we don't get the errors. So we should be able to see more about the code, right?

Ah, there we go.

Beautiful. Look at that. What a cool -- like this is -- that in and of itself is worth the price of the setting this up, right? Like, that's such a handy thing to see that, like, hey, lots of people are getting an error. This is the code. Go look at it. And I assume that if this is hooked up to, like, my GitHub or something, it would theoretically be able to kind of point me right to that file?

Yeah. We've got that, too. In a week. I think that's coming out.

Oh, nice. Very cool.

Took us a little while, but, yeah, we have that, too. So you can pop directly to GitHub. Sentry is -- there is a whole bunch of stuff going on in 2021 with Sentry. We could even try this performance tab and see what happened there. You did actually install the tracing library, so there might be some other magic stuff in there. Yeah.

Okay. Let's see. All right. Okay.

You have a very fast website.

Thank you very much.

These are pretty quick numbers. So, if you scroll all the way down, so -- and you can click, you know, that slash. This is probably the trickiest thing about a React app, is that there is no sort of default routing.

Right.

Library, right? So if one wants to sort of, like, truly instrument this performance stuff, we can spare people's IPs, but if we truly wanted to instrument people's performance page, you kind of need to know at the routing level whatever the URL is. That's hard to figure out out of the box for Preact to react. If you use URL router, you can install our Sentry router thing and there are some instructions. That actually requires a little more instrumentation.

Sure.

You can get the proper URLs. But click -- go forward -- go back to that sort of, like, transaction page.

Okay.

Basically what we give you, if you scroll down and we hit -- so this is like -- this is supposed to be like a performance overview of your page. People who have just been sort of hitting the website. Shows you slowest and stuff. Again, you've got a super fast website. It's not super slow. If you click one of those individual events. Scroll -- that table right there where it says duration. Ooh, 12 seconds. So, we also -- if you -- we kind of do a whole kind of, like, Waterloo graph of what pass ets are being loaded, what is the browser being locked on, you know? To help you understand -- to help you build performant pages.

See, this is on Android. So, let's see. Firefox mobile. Over Wi-Fi. And so how do we -- what do we, like, thinking about this, is this, you know --

This is a single event. This is, like, one user's experience. And it's almost like, if you can think about the network tab in Google Chrome or Firefox Dev Tools, this is trying to recreate that.

Yeah.

With the difference, again, being it's kind of the same story. If someone has a slow website, hey, can you open up, you know, Dev Tools, open up that network tab, send me a screenshot. What if instead we captured that for you optimistically or proactively? And then you can kind of look at the real user experience. Right? So this is a lot to just look at. It's a little different from an error which is, you know, we knew that there was an error.

Right.

Here is a problem. Here is a stack trace. Performance is a little trickier, right? Is this a slow page? That's up to you. That's up to the developer to decide if this is anything that is actionable.

We can see, I can see, for example, this is blocked on this resource being loaded. So, you know, could I preload this to get it into the browser faster? Could I preload, you know, all of these things so that they're already kind of ready because I know I'm going to need them on the page. Then I can make a decision. Do I want to add a bunch of link rel preload.

Was that the deploy preview?

It's the deploy preview, but they're effectively the same thing. There's not a lot of differences there.

Maybe this is like letting everyone consume those modules directly. I would guess why it's blocked is because you hit max parallel downloads on the browser.

That could definitely be the case.

It looks like it kind of hard stops and waits there.

Mm-hmm.

It doesn't seem like any other good reason, other than parallel downloads, right?

Yeah, I mean, this is a pretty sizeable chunk of things all happening at once, right? But --

And now you get to -- you have this visibility, right? Before, this was just an anonymous experience on the internet that you may or may not have understood. And, you know, the sort of other values there, to give you a whole wholistic, high-level view of the experiences, right? For the most part, 79% of users are having a good experience, right?

Mm-hmm.

But it seeps like there is some, maybe 1/10, having a slow experience.

Right. And figuring out is that something that we can control?

Mm-hmm.

You know, that kind of comes down to that really challenging, like, I don't know, sometimes you can't. It does look like there are decisions we could make. There are scripts we could remove. There are things we could take out of the mix that would squash this down, so even somebody on a feature phone over 2Gs is going to get this super fast.

Yep. This is the same vital stuff as Light House, I think Light House is doing synthetic. This is real user scores.

Yeah. Somebody asked a question which I also have. This user misery. Does this mean there is a lot of misery?

It's a very subjective score. Which is -- and I think that we use that number universally, whether you're doing a back end API endpoint, so, I don't think it's fair. 10 out of 11 users waited more than a second for this full page.

Yeah, I Koch yeah. We are -- it takes a second to load. And it's also really hard to quantify this sort of stuff because, like, when is the page actually loaded? Because it looks loaded now, but it's definitely not. There is a bunch of stuff happening in the background that needs to be refreshed and so on and so forth.

This is good feedback, by the way. We introduced that user feedback, the user misery score before we had web vitals in there. So, you know, when you have the vitals, which I think gives you a way clearer idea of what users are experiencing, the that's more of an artifact of the world before sentry captured and reported on web vitals.

For sure. Okay, if I go-to fix this, what's my work flow for fixing this? I'm going to set up an integration. I'm going to integrate this with GitHub. Let's do like a real --

I'm not even kidding that is something that is in the works that I think we're launching very, very soon.

Will this let me open an issue?

Yeah, yeah, you can do that. Absolutely.

So, let's go through the triage process. I'm going to configure century and get it added to my site. Well, we'll just let it have -- sure, this one. Not that one. We need learn with Jason. Oh, my God, I have so many organizations. All repositories on Learn With Jason. I can close this window now. All right. So I have now done this and I want to add this as an issue to my GitHub. So, if I'm going to do that --

It's located in a crazy place. It's there on the right side on the bottom. So scroll down on the right. Set up issue linking. There is a call-out there.

Oh, okay. Perfect. So then I click this?

Yeah. It's like what happens here?

Add installation.

Didn't we have this? Maybe it's -- close this window. This is a good test, by the way. I'm sure we have -- see configurations there?

Oh, okay.

Listen, I hope some of our developers are watching this.

So I'm going to add a repository and I want this to be learned with Jason.Dev. There we go. Okay. So then if I go back to my issues and I click on this issue and say, I want to create an issue, 50.

What's going to happen? Oh, no.

Let me refresh.

I don't know. Even actually I don't know the next step here if you've gotten to that effort.

Okay.

Might just bail out on this entirely.

Okay. Yeah, so maybe we're not there yet? Share. No. Oh, that's kind of cool, though. I can share this and then I can send this to the chat and y'all can go look at a Sentry error and kind of poke around in there.

There's a question. There's a question from the team. Does Sentry use Sentry? The answer is yes. Of course we do. I wish that Sentry told us when there were massive UI failings during someone's onboarding experience, but alas, we're not there yet. Maybe next year.

That's okay. What we're going to do is fix this bug. I'm going to go back in here, I'm going to fix the bug. We're going to save it. Then let's git commit.

Before you do that. Let's do one thing. Let's go back to the UI. So, there is this resolve button, right? Just hit that. Just say, hey, I fixed it, okay? Often what we do when we fix bugs is, yeah, I fixed that bug. But did you really, right?

Okay.

Because if you don't, again, you know, you go through this long cycle where you deploy it, you do one of these, you walk out the door, and then you get an email from support the next day, hey, actually, we didn't fix that problem.

So let's pop back into our deploy preview here. And let's trigger this bug again.

Yeah, I mean, if you just trigger that again. Sentry will go, wait a minute, I've seen this before. This isn't actual fixed, right?

Going back.

It clears it from the list for now because, you know, it believes that you resolved it. But should we just go and, like, if we trigger that button, in a perfect world century will go, hey, wait a minute. This is a regression.

Yeah. Let's do it. So I am freshening the page. Here's our bug. Here's our bug. Oh, no, it did the thing again. Here's our bug. Woof. Okay. All right. So now we've got -- now we've got our bug re-triggered. And, wait, I think I cleared the wrong bug. So this, I think, is the one that's happening. Whatever the most recent one. It should be any kind now.

Yeah, so probably depends. When they have different signatures, again, it's like, you know, you had source maps that applied to some of them and not others and expanded the signature name and will give you a more clear Stack Chase.

All right. Here's what I'm going to do. I'm going to resolve all of these because I've -- let's resolve them all. I'm go to trigger this, mute this tab so it stops doing that. And then I'm going to trigger our error. There's our error. Okay. So now that I've triggered it and I go back.

Yeah, let's see what happens.

It's back!

It is back.

You probably have something in your inbox saying, hey, we determined that's a regression. Perfect world here, you verified your email. Hopefully this is working.

Here we go. I have a regression.

There it is. So, you know, if you use century and kind of use it for the work flow, not just the reporting. It has some handy, helpful things. And that resolve button, by the way, if you want to -- you see that drop-down on the resolve. Just some other options here.

Oh, interesting.

You can augment your experience with Sentry. If you tell ups about versions and releases, we can do clever things. Hey, I'm about to hit deploy on this fix. I'm going to mark it as resolved now, that way it will stay cleared and when the next version rolls up, if we actually see -- if we see a user come along and trigger that same bug in a subsequent version, we'll know that was a true regression.

Right.

And this is important because while you're deploying the fix, might actually still be hammering the live live error.

Yeah, that's fair. We want to make sure it's linked to the fix and not artifacts. That totally makes sense. Then the other thing I'm thinking about is, like, this one, we know someone was kind of messing around in the console to cause this error.

So I don't actually think this is true. I think this is a different signature because it's a different browser. Just windows there. Could be Chrome versus Firefox.

Maybe. Does Chrome have an event.this? That would be fascinating.

This is really tricky for us. In every browser or JavaScript it would generate the same strategic, which is not true. We've tried to do a lot of work to normalize things town to their natural elements. Two day from now in a chrome update might look different. There are certainly conditions whereby things are different.

Okay. Yeah, no, that totally made sense. Okay. So let's assume that it was something where, like, someone is making an error on purpose? I'd be able to go in here and say, okay, we know people tried to hack our console like this. I'm going to ignore that one. I won't get notify even if it continued to happen.

Yeah, it will clear from the list. You can always see that you can find it. It's buried intentionally.

Right. So I would do, like, I could do ignored errors.

This is a good question. It's probably, like, is:ignore. We've got some more tabs shipping soon.

For me, this as a GitHub user is pretty familiar. This is how you filter features. Once you learn the pattern, it's very straightforward. You've also got a search builder.

That's probably one of the first things I built when I joined Sentry still hanging around. I know. That's always the way. Also, I saw DJcheesyP mentioned thaw Yvonne hey a dark mode. I want that. How do I get my dark mode?

That's a good question. I expected DJCheezyP to tell us. There are organizational settings and personal settings. Shift P, wow.

Shift P?

I don't know.

I don't know that one.

If you hover over your rent rated user Avatar in the top left. I have my user settings. I tint know that was clickable. You can do a theme there.

Nice. And now we are the night. Okay. So this, beauty. Yeah, look at this thing. So we're in here. Now we can actually handle this error. We've got our error ready. We found the bug. I'm going to push it. We're going to watch this thing rebuild. We don't really need to let it rebuild. Instead, we're going to let it sit in the background.

I can answer a question. Ryan asked can you prepare this by line, character number to edit those slight variations? So, it's possible. There is sort of like a -- we call it a fingerprint. There is a default fingerprint that is generated. You can override that. Service side fingerprinting rules you can change. Also in the client library, you can change -- you can basically know your own Firth print based on what you know. Browser JavaScript is probably the worst for these variations. You know, if you're, say, running Node --

Right.

And you are only running one version of Node in production, which ideally you are, you're basically going to have complete inconsistencies. Same for every platform, Python, Ruby.

Nice. This is pretty powerful stuff. So, from here, we've got a couple options, right? We could try to instrument more things. We could dig into some advanced work flows. We've got about 30 minutes. What do you think is the right use of our remaining time here?

I almost want to call this a success and hang out.

You know what? If you want to call it a success, we can always do that. I don't always think a longer episode is a better episode. We can field some questions and call this one a high five. Look how great that was we got all this done in an hour. But, yeah, I mean, looking at this for real, I really do think this is a nice work flow. Getting alerted when things go wrong. Being able to see exactly where the code is is breaking, and being able to do this in a way that's not getting alerted on Twitter. That's not me noticing it the next time that I open the site and realize, oh, my God, I can't believe I left this in production for a week and a half. And, you know, when we talk about this from a usage standpoint, so if I go to -- how do I get to the Sentry homepage if I'm logged in?

It's Sentry.ao/welcome.

Okay. If I go to Sentry.io/welcome. We'll look at pricing here. It looks like I can do quite a bit on the free package here. I've got release tracking, support for languages. It looks like maybe the reason I can't do the third-party integrations is because I'm not on a team package. Maybe it just needs to tell me that. But, yeah, like, this is pretty slick because I can get the email notices and I can get the regression checks. So one question that I do have when we're talking about this is, like, I don't necessarily want to get emailed every time there is an error. Because, you know, people are messing around and maybe they try something and it's going to cause an error. How could I say, like, if an error's happening more than once or more than a lot.

So, let's go to an alerts tab. I think that is something worth going over really quick. You'd expect that there is probably a default alert. So, let's create an alert rule.

Okay. And so we can choose our environment?

Yeah, we have a clever alert builder. I'm learning we probably turned off alerts for new users. I'm going to check that out. Which is why that table is empty.

Oh, I got it. Okay.

We play around with a whole bunch of things. I lose track sometimes.

You got to iterate. Ship fast, you learn and make adjustments. Okay. I want to make an alert. My alert is called "it's busted." And when an event is captured, and all of the following happens or any of the following -- okay, so that makes sense to me. I can say, ooh, here we go. This is what I want. The issue is seen by more than, like, X times in Y amount of time.

Mm-hmm.

Or by more than X people in -- okay. So, I want to see this -- if it's seen by more than, I don't know, let's say three people in one day, that's when I want to get the alert. So, now, does this mean as soon as the third person sees it, I get the alert or tomorrow I get the alert?

I think the third person.

Excellent. That was -- that's what I would hope would happen. And then it will create a new issue.

So that's actually a separate rule. So, an issue is like a grouping.

Oh, oh, I see.

Whenever we find -- it basically means whenever we find something with a new fingerprint that we haven't seen before, we can contact you, right? Then if it happens a million times after that, you won't get a second email, just the first time we see any fingerprints. So, that's one capability.

Nice. Yeah. So this is -- this is great. If there are no matching issue owners determined by ownership settings, which means it would just default to me.

Yes.

If I add more people to my team, I'd be able to give each person an area of ownership. Because we'll set up those ownership filters, will email just the people who need to know and not everyone on the team.

Yeah. Let's see that drop-down really quick. I just want to. Team, member. Yeah, there is even concepts of teams so you can set up teams. You can have an alert, you know, basically like a user group, not unlike in GitHub. You can have every member of the user group contacted. On the sort of team plan, yeah, you can configure Slack or Microsoft Teams, this is where you would blast that into a channel or whatever.

Got it.

That rate limit, you know, can also stop you from hurting yourself by creating a rule that is maybe so noisy that it just goes off the rails all the time.

Right. Because, like, even if -- even if I did want to get alerted for over new error, I probably don't want to get more than one email every five minutes. That seems like it would hurt my feelings. It gives you a chance to bail out. You can say, okay, I'm getting way too much of this error. I need to go chill out this alert, as opposed to waking up to 15,000 emails in your inbox. Not that I've ever set up alerts that did that to me.

Mm-hmm.

But, yeah, no, this is -- I mean, like, I think this is really, really cool. And what I like about this, too, so everything that we've done so far is this is available on the free plan. So as an individual site owner, I could set this up for my own site. Or if I'm building a web app on my own, I can set this up for my own web app and I can operate on Sentry. It's just when I start working with a team, when I want more integrations, that I go up to the next plan?

Yeah. So there is sort of like a volume limit, right? Which is -- I believe that's somewhere in there. But, yeah, 50,000. The exact number eludes me right now, but, you know, for people who are doing casual side projects, you can go pretty far with that developer plan. But if you have serious traffic or, you know, you're a bigger team or whatever, it's 5,000. All right. Then, you know --

Yeah. What I like about it, it scales with the importance of the project that you're putting up, right? By the time you get to the point you're doing a lot of things you'd need in a team, you probably have some kind of revenue coming in. So it supports the idea of, like, I'm doing a thing for a hobby project, but I really do want to make sure this hobby project is quality, then this is great. Set this up. Get your insights and be aware if something is wrong. When you start make money, start taking it seriously, you know, you get that co-worker, now you're going to, like, bump this up. Let's go more production. Then you get bigger and bigger, and I think that's -- I like that model, where you get to start super small and you're not forced to immediately jump to the $50 a month plan, you know?

I use it for my pet projects as well. Over the holidays, I wrote a little bot to figure out how to buy a video card in this crazy climate. Instrumented that with Sentry. And discovered all the ways that I am not a very good programmer. [ Laughter ]

Yes.

And, frankly, that's helpful. When you're writing an inventory scraping bot, you want to know when it's not working. Otherwise, you'll never be informed when the thing you want is available. You'll just go on wondering forever, does this thing even work? Which I did for a little bit.

Yeah, exactly, right? And I think the thing that is really exciting about this, you know, we did -- like, including messing around a little bit, including, you know, exploring and me wandering off on tangents, it took us an hour to set up full instrumentation where now I'm going to get notified if something is going on with Learn With Jason, and that is really exciting. Now, I know we can take this further. Like, I imagine I could fry to catch, you know, can I do things like catch 404s or catch 500 errors and stuff like Sentry as well?

Yeah, I mean, that sort of, like, automatic instrumentation -- I would check out, like, bring up the JavaScript talks. You can do docs@Sentry.io. There are obviously different platforms, but the experience that you followed is sort of the -- what is a good level of value we can provide out of the box by just making decent assumptions about, you know, what's going on on your website? But you can do other things. You can, for example, those user counts are based off of IP address, okay? Just a guess. Maybe an IP address is an unique user. You can choose to anonymously identify your own users by sort of adding context, right? So you can choose to -- if you want to, you can just actually directly identify them so that you know, hey, John Doe hit this bug. If that's an important -- hey, maybe if you're a company and you -- maybe John Doe is an important customer to you, you can actually reach out to them proactively and say, hey, I know you've experienced this bug. We've already shipped a fix and you shouldn't have it again.

Right.

We used to do that a lot in Sentry's early days. That is a great experience as a sort of customer of a product. To learn that, you know, I didn't even have to go tell them that something was wrong. They reached out to me to let me know something was fixed. So that's something you can do. If you want to be more privacy conscious, depending on what data climate you exist in, you can just choose to hash that email address or user ID. So you can identify users and bucket them directly but not necessarily know who they are. So the numbers are good, right? A lot of capabilities there. You can set your own tags. You can do stuff like, you know, seem tags that we use are customer type, plan type. Is this person on a team plan or a business plan? Is this a bug that is occurring to a very specific segment of users? Not just sort of like the default ones, like what locale they're coming from or what browser they're using, but maybe we have them in a split test group and that test group is experiencing a bug, and it's just that group, right? That's going to go a long way to help us identify what the cause is. There are a lot of hints and things that you can choose to go further with.

Yeah.

To help the system out.

Yeah, yeah. And this is also, like, I love the idea that, you know, by default, you're providing really helpful -- the experience is good out of the box, but if I want to go in deeper, I can just pull in this Sentry object and do more stuff, which I think is a really -- that is a really powerful model. And, you know, like, things like being able to identify the transactions or, like -- is attachments what I think it is, where I can just straight-up throw something in here and it shows up in Sentry?

Yes. Yep.

Because that, I mean, I don't know if that's a practical thing to do, but it's pretty dang cool.

I'm impressed we have this example from JavaScript. I hadn't actually seen this. But it is something that we support. It's more common on some platforms. So we support, like, games and, like, VF platforms. So you can attach, like, a crash dump, for example.

Oh, I understand. Yeah, that makes sense. So, another thing that I could do here is if I was, like, if I were to be fetching something and I got -- I got back an error response in my, like, catch, I could, like, do this stringification of whatever came back in the catch?

So, we have first-class support for HTP responses as well, too. So that's another thing you can do, too. Attachments is more sort of, like, you know, here is a binary blob that is going to go, you know -- is gonna, like, imagine it's going to go to S3 under the hood, but sort of correlated with the event. Then you can download it later.

I get what you're saying, yeah.

Again, you know, we looked at a very sort of front-end JavaScript sent -- centric approach. If you were wiring this up With Ruby or rails or Flask or Jen FWSHGS o. It will get injected into the event that you saw. So the experience is different for every platform. It's kind of, like, tuned to that platform to be -- to give you, like, again, decent -- really good value for that platform.

Yeah. So if we swap over to PHP or something --

Mm-hmm.

Or I don't know, one of these. Here, Rust. Rust tooling. We like Rust here. This is fun that this exists, that this is a thing you can drop right in, right? It's just nice, like, to be able to say, you know what I don't want to deal with today, is setting up my own instrumentation and just being able to say, like, please give me a pretty dang good starting point. As I learn more about the way errors happen in my app, I'll go in and further customize it so that I can get better reporting, better alerting, better ownership and all that stuff. Those are all the things you eventually have to do that because, like, I remember being at teams where, you know, I'd join as employee number five. By the time we're at 65, everybody's still getting emails every time something goes wrong. Okay, we need to clean this up a little bit. We're going a lot of noise and a lot of people are starting to ignore their email because they get too much, like, email spam. They're like, well, email goes off all the time. I don't need to look at that. The GitHub alert issue. If you get 500 alerts a day, you're not going to read them. So you miss important alerts. So this type of specialization we can do here and set, hey, if you get an email from Sentry, it's because you own that issue and you are the one that needs to deal with that, which I think is a good approach.

I want to bring this full circle. We began this conversation saying, hey, a lot of people don't do this, right? If developers are experienced with a version of this, specifically back end developers, they're familiar with logging. So what is logging? Well, you're, you know, every print statement, every Stack trace, everything that would, you know, go out to the terminal wing in local development would go to some file, right? There is certainly more advanced logging tools that can do alerting on stuff that goes into a log file, but, you know, if you imagine log files as being texts primarily, or maybe even structured objects, they don't provide these levels of capabilities that we kind of touched on, right?

Mm-hmm.

Resolving. Ignoring. Fingerprinting certain events. Level of implementation for bread crumbs or all this jazz. This is a very sort of curated approach for, well, I really want to understand errors and performance primarily. And so that's where kind of all this stuff comes from. Your comment about the GitHub notification problem is absolutely apt. That is why there is a code owners' like feature. Arguably URL. We were talking about a production application and not purely source code. We can look at other attributes to assign ownership on. URL is another good one. If maybe in a company I own the store, store.company.com. Anything under that URL could respond to me, for example.

Absolutely.

That felt like a cogent opponent.

No, it really is. And I think it's such a critical thing. And so, yeah, I think, like, coming from here, this actually does kind of feel like a good place to wrap up because we've shown, like, how far this could go. How customized it can be. We showed how quick it is to get started. We looked at the UI. I feel like this is something that I am definitely excited to put into my hobby projects and to start looking at, like, how can this be, you know, useful to me and how can this be something that saves me prom a bunch of stress that I cause myself by shipping code that's not as stable as I thought it was when I merged it? And, you know, I think that's a -- that peace of mind, especially when you're trying to drive a bunch of traffic to your blog or you're launching a new feature for your hobby project and you want to put it on Product Hunt, the last thing you want to do is, you know, do your soft launch and nobody reports a bug until you go live and you immediately realize that, like, the most important part doesn't work for anybody on the Firefox. So being able to get those error logs early and get that information before it becomes an issue in the product hunt thread, that's a really powerful thing. So, with that being said, Ben, are there any resources that you recommend for people who want to dig in beyond what we did today? Not to put you on the spot. We've got docs.Sentry.io. These look pretty comprehensive.

Sign up for it. Go through the onboarding flow. It tries to hold your hand and help you be successful. Yeah, docs are here. I don't know that I have anything. I guess we have a resources section somewhere on our website on the bottom, you know, one of those. Like on the marketing page. Where resources and tutorials. So there is a bunch of -- yeah, sort of like --

A whole bunch of stuff in here.

Maybe you already use Sentry and you want to understand, you know, advanced mode. There is some cool stuff here. There is some marketing stuff here, too. So those are some of the things I would check out.

Nice. Cool. So, yeah, we'll drop the -- I'll drop the resources link. You can go hunt around the site for everything else. And with that being said, let's do another shout-out to Ben here. Thank you so much for coming on and showing us all around this product. Go follow Ben on Twitter and get all that good, good information. Also, another shout-out to the sponsors. We've had Jordan with us all day putting up with my jibber jabber doing live captioning. That's from White Coat Captioning. Very much appreciated. And we have that made possible by Netlify, Fauna, Auth0 and Hasura, all of whom are kicking in to make this accessible for more people. Chat, thank you so much for being so active today. Cheers and gifted bits and DJCheezyP is saying there is a discord. Let me grab that as well. Here is a Discord link. You can do that. Is that, like, a good target for people getting started.

Yes. Thank you, CheezyP. Very good save there. There is a Discord channel. We're trying to build that up. Say hello. That will be helpful.

Absolutely. Cool. With that being said, make sure you go out and check out the schedule. We've got a lot of really fun stuff happening coming up on the show. Later this week we have Abhi coming on to teach us on state machines on Kubernetes. I honestly don't know what that means, so I'm really excited to find out with the best of you. Ben Hong is going to come back and teach us Vue and serverless functions. ES build, it's so fast and so fun, an interesting alternative to things like Web Pack. That's going to be a good look into the future. We've got Jennifer coming. People I haven't put on the site yet. Wes Boss joining us. So good. We're going to do an episode with Jonathan Berger, use React to create videos. Pretty excited about that. That's going to be fun. Anyways, chat, as always, thank you so much for hanging out with us. Ben, thank you so much for taking your time today to teach us how to use Sentry and just generally be delightful. I very much appreciated it. Any parting words before we call this thing done?

I'm just going to say thank you, chat. Jumping in on that. Thanks, Jason. I was only mildly embarrassed walking through our own product, but I had fun.

A good time, right?

Yeah.

Awesome. All right, chat. Stay tuned. We're going to go find somebody to raid. Ben, thank you so, so much again for hanging out with us. We will see you all next time.