This episode is for members only

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

Get started
Already a member? Sign in to continue
Playing
25. Updating the job

Episodes

0%
Your progress
  • Total: 4h 59m
  • Played: 0m
  • Remaining: 4h 59m
Join or sign in to track your progress

Transcript

00:00
Before we update our job to store the response we get back in our new checks table, we're just going to take a moment to update the frequency just so we don't need to wait around for as long. So I'm going to go ahead and set these to 10 seconds just to make this a little
00:15
bit quicker so we can get a little bit more feedback about what we're building. Okay, so we've already seen some of the methods that the HTTP client in Laravel gives us, and we know that we have the checks relationship on the endpoint model now. So really what we can do underneath here is access the endpoint checks relationship and just create a record out in here
00:39
for every single check that we perform. And we know that we want to go ahead and store the response code, and we want to potentially, if the request was successful or not successful, store the response body. So the response code is pretty straightforward. We're going to go ahead and access the response and grab the status from it. So let's just put in there directly,
01:02
but with the response body we want a condition in here. So if the response was successful or was not successful, we want to go ahead and store the response body. Otherwise, of course, we just want to store a null value. So let's just access that as a method, and we are done. Okay, so the next checks in here, let's just go ahead and set these to the current date and time, like so. And we're
01:29
going to come over to our console here, and we're going to go ahead and run our short schedule. So let's run that, and we can head straight over to the database under the checks here, and you can see that already these checks are being performed. We've lowered the frequency here to 10 seconds, which means that if I just keep on refreshing this, sure enough in 10 seconds
01:47
we start to see the rest of the checks roll in. Now let's just go over to our endpoint and just change this over to something that doesn't exist again, like pricing. And if we save the changes here and come over to checks, sure enough in a few seconds we should see the response code set to 404, and we should see a response body in there as well, which we do.

Episode summary

In this episode, we're making our job a bit more efficient by updating how often it runs, just to speed up our feedback loop—no more waiting ages for checks! We bump the frequency to every 10 seconds so we can see updates in near real time.

Then, we dive into using Laravel's HTTP client and our established model relationships to start saving the response data from each check to our new checks table. That means for every check, we're capturing things like the response code and, if the check fails, the response body too. We only save the response body when necessary—otherwise, it's set to null.

Once everything is wired up, we hop into the console to run our short schedule and watch as new entries appear in the database every 10 seconds. To test it all out, we even deliberately break an endpoint to see how 404 responses get logged. Sure enough, the failed check shows up with the correct status code and body data, which is exactly what we want!

This episode is all about tightening up our feedback loop and making sure our job is storing meaningful data as it runs.

Episode discussion

No comments, yet. Be the first!