Build An Uptime Monitor with Inertia

Sign in Get started

This episode is for members only

Sign up to access "Build An Uptime Monitor with Inertia" right now.

Already a member? Sign in to continue

Playing

39. Creating an endpoint recovery notification

Episodes

0%

Your progress

Total: 4h 59m
Played: 0m
Remaining: 4h 59m

Join or sign in to track your progress

01. Introduction

01. Introduction and demo

02. A fresh Inertia project

02. Sites

03. Site and dashboard setup

04. Building the site selector dropdown

05. Making use of API resources

06. Setting the default site

07. Setting up Vue modals

08. Creating a site

03. Endpoints

09. Setting up endpoints

10. Enum endpoint frequencies

11. Creating the endpoint form

12. Storing an endpoint

13. Validating and authorizing endpoint stores

14. Normalizing the endpoint location

15. Displaying endpoints

16. Deleting endpoints

17. Toggling inline editing for endpoints

18. Applying a watcher to the endpoint form

19. Storing endpoint edits

04. Checking endpoints

20. Determining endpoints to check

21. Creating a job to perform a check

22. Making an HTTP request

23. Scheduling checks every second

24. Setting up the check relationship

25. Updating the job

26. Showing the last status

27. Expanded list of checks

28. The response body modal

29. Authorizing the endpoint details

30. Calculating uptime for endpoints

05. Queuing

31. Setting up queues

32. Queuing the endpoint check

06. Email notifications

33. Setting up email in Laravel

34. Site model email notification storage

35. Adding email addresses via the UI

36. Listing and deleting email addresses

07. Downtime notifications

37. Observing when to notify

38. Creating an endpoint down notification

39. Creating an endpoint recovery notification

40. Making the emails a bit friendlier

08. Extras

41. Deleting sites

42. Eager loading

43. Recovery notification bug

44. No sites fix and placeholder

Transcript

00:00

Now that we are checking for downtime and sending a notification, we're going to move on to check recovery. So we pretty much want exactly the same logic, just the opposite. So let's go ahead and just start out by creating an if statement in here. Again, we're going to split this onto two lines.

00:18

It's going to be very similar to this one. And of course, when something is recovered, it means that it is a successful check. So really, we just want to go ahead and say is successful. Now, we can't obviously just leave it at that, because what's going to happen now is every single successful check is going to produce a notification, which is not what we want. So we're also going to

00:40

say if the previous check, much like we did up here with the previous check checking if it was successful, we're going to say if it wasn't successful. So check previous. And once again, we are going to go ahead and optionally grab that is successful, because of course, we may not have a previous record. So downtime is if the check is not successful, and the previous

01:02

check was successful. And recovery or uptime is when the check was successful and the previous one wasn't successful. We also might want to add on to here, just checking the endpoint checks count is greater than or equal to one because there's no point sending out a recovery if we don't have any checks. So with that done, that is the logic pretty much just the opposite.

01:29

We now just want to implement the event, the listener and the notification to notify everyone. So let's go ahead and do that now. We'll go ahead and create an event first. So PHP artisan make event. And we will say endpoint recovered. And let's go over to our event service provider, copy this, change this to endpoint recovered. And what do we want to do send

01:57

recovered email notifications. So let's comment this out, go ahead and grab this, we can generate these from the command line, but I tend to just go ahead and specify them in straight away and build them out myself. So listener, and send recovered email notifications. Let's bring that back in, pull the namespace in for this, just make sure we pull the namespace in for this.

02:18

And we can now go over to this. Now, there's a lot of copying and pasting here, because we're pretty much doing the same thing. So if we just grab that and come over to the recovered section here, let's go ahead and pop this in handle. And let's go ahead and pull in the notification facade. And the endpoint down notification obviously doesn't apply here.

02:37

This is an endpoint recovery notification. So let's go ahead and create this out. php artisan make notification, endpoint recovered notification, like so. And we can go ahead and switch this out endpoint recovered notification. And let's go into this and just grab the notification that we had before for

03:08

our endpoint down, just the mail message part, that's fine. And let's go ahead and add this in to here. And again, we're just switching things out. So let's say, recovered, and we don't have our endpoint pulled in. So let's pull that in now. And endpoint, and we should pretty much be good. Of course, we just want to switch this out. So

03:31

let's change this to recovered, still want to pass the endpoint down. And let's create the view out to handle this endpoint recovered blade, php. And we'll just copy this paste over and say recovered. Great. Okay, so we should be pretty much good to go. Now, let's just try this out. By making sure that we have cleared everything out. We'll start with a location that works,

03:58

fail it, get the notification, recover it and get the recovery notification. So let's go and just clear everything out of the database, first of all. So let's clear out all these checks. And let's clear out our jobs. And that should be everything we need to do. Let's come over, that's all clean. And I'm actually going to edit this to be a homepage. And let's come over and

04:23

run our queue. And let's run our short schedule. And of course, we're going to start checking, we should see the status rolling. Now, let's go over to our mail client, just delete all of these. And just to keep things simple, I'm going to get rid of one of these email addresses, just so we can keep track of this. So let's go ahead and change this to ABC. And of course,

04:46

if we come over here, we should see an email roll in, telling us that our endpoint has gone down. And there it is. So our endpoints gone down, what's now not going to happen is every single time we check this, it's not going to send another email, we already saw that from the logic that we created earlier. So 10 seconds goes by, we're not going to see another email roll in,

05:07

we're only going to see an email roll in when this endpoint has recovered. So let's recover this in that fake way by just changing the location over. And then we'll just wait for a recovery email to roll in here. Now, it doesn't look like we have received a recovery email. So we're going to have to check out what is going on here. I believe if we come down to our check observer,

05:32

yeah, we didn't actually dispatch the endpoint recovery event, that would help. So let's go ahead and say endpoint recovered. And we should be good. Now, a really important part that we've not mentioned yet about our queue is that when we make a change to code, we need to cancel this off and rerun it, you won't need to do the same for your scheduler. But we're going to rerun our

05:54

queue worker here. And if we just give this a refresh, that has recovered. But we're going to go ahead and go through this whole process again, because obviously, we're a little bit late. So we're going to go ahead and put this down by changing the location over. Of course, we get a went down email, let's go ahead and change this back to technically recover it. And we should see

06:15

once that's recovered, this time around, because we are dispatching that event, an email actually roll in, and it still is not here. So a good way to check this when you have a failed job is you have a failed jobs table. So you can very easily just come in here, grab the exception and expect that. So just to inspect that, I'm going to go ahead and paste into here, and we'll just get the

06:36

output. And you can see here that over in the endpoint recovered event, we don't have a check property, that would help. So really helpful that we can actually inspect that. So let's go over to endpoint recovered, and endpoint recovered event. And of course, we didn't pass the check in. So that would help. But of course, Laravel has dumped that exception in here. So that's great.

07:02

And there we go. So third time lucky, of course, we're going to go ahead and cancel off our event here. We're going to go and rerun it, our queue, sorry, we're going to rerun it. And we're going to go ahead and fail this ABC. And of course, we should see that roll in which we have. And now we're going to go and recover it. And now that we've fixed everything up, hopefully,

07:26

we should see a recovery email finally roll in. And there it is. So this recovered. Now, obviously, the URL is different, because we're just testing this by changing the URL around. So it's a little bit confusing. But you kind of get the idea if we had this as the same URL, and it did actually recover, then of course, it would show the same endpoint here. Okay,

07:48

so that is now the logic to go ahead and notify the user over in our check observer, that the endpoint has recovered. And of course, notice there are not loads of recovered emails rolling in, because our logic prevents that. Let's finish up by just making these emails a little bit more friendly with Laravel's markdown email functionality.

Episode summary

In this episode, we're taking the next step by not only detecting when an endpoint goes down, but also when it comes back up—basically, we're setting up a recovery notification system.

We start by updating our logic to detect when an endpoint that was previously down becomes available again. This involves adding a few new checks to our code to avoid spamming users with recovery notifications every time a successful check happens—only the first successful check after downtime should trigger an email.

From there, we jump into Laravel and create the necessary event (EndpointRecovered), listener, and notification. The process is super similar to how we handled downtime notifications, so there's a bit of code copying (with some tweaks). We set up everything from the backend logic to the email view that the users will see.

Next, we do some actual testing by triggering downtime and recovery, making sure emails are sent at the right times. Along the way, we hit a couple of bugs (always fun!), and we fix them—like remembering to dispatch the event and pass the correct properties. We also look at the failed jobs table to help debug what's going wrong.

Finally, once everything works, we take a quick look at making our email notifications friendlier using Laravel's Markdown email functionality to clean up the format. By the end of this episode, we've got a robust notification system that avoids duplicate emails and lets users know exactly when their endpoints are back online!

Episode discussion

No comments, yet. Be the first!