HOSTING / LESSON 09
Monitoring & Logs.
Keeping an eye on your application
Loading the lesson…
Loading activities…
Browse lessons
HOSTING / LESSON 09
Keeping an eye on your application
Loading the lesson…
Loading activities…
Your app is live. Cool. Now how do you actually KNOW it's working? And what do you do when something breaks? This lesson covers how to keep an eye on your Railway app and use logs to track down problems and fix them.
When your app runs on your own computer, you see everything. Error messages pop up, results show on the screen, you're sitting right there.
On Railway, you're not watching it. Your app could crash at 3 AM and you'd have no clue until a user complains. That's the whole reason monitoring exists.
A client once asked me what happens to their site if I die. Morbid question (fair though). It's what pushed me to rebuild my whole agency around real systems, so things keep running and problems get noticed even when I'm not the one watching. Monitoring is that same idea, just for your app.
Here's what monitoring does for you.
Logs are messages your app writes about what it's doing. Think of them as your app's diary.
Every line tells you something that happened. When stuff breaks, logs are your best friend for figuring out why.
Railway makes your app's logs easy to get to.
Go to your Railway project and click on your app service.
Click on "Deployments" or look for a "Logs" section. You might see tabs for different types of logs.
Railway shows logs in real time. As your app writes new messages, they pop up instantly.
Railway shows a few different kinds when you open a deployment.
Build Logs - Messages from while your app was being built. Useful for fixing deployment failures.
Deploy Logs - Messages from your running app, meaning anything it prints. This is where errors and activity show up.
HTTP Logs - One line for each request that hits your app, with things like the path and status code.
A log message usually has a few parts to it.
Each level means something different.
When you're hunting down a problem, go straight for the ERROR messages.
Your app can write its own logs that show up in Railway. Here's how.
Anything you print to the console lands in Railway's logs.
Logs aren't the only thing worth watching. You'll also want to keep tabs on how many resources your app is chewing through, and Railway shows you these.
How hard your app is working. High CPU means it's crunching a lot. Stuck at 100% for a long time might mean a problem.
How much memory your app needs. If it just keeps growing and growing, you might have a memory leak.
Data going in and out. Handy for understanding usage patterns.
Click on your app service in Railway.
Find the "Metrics," "Usage," or "Observability" section. You'll see graphs of resource usage over time.
Look for spikes and trends. A sudden spike might mean a problem. Steady growth might just mean you're getting more users (nice).
How do you catch problems EARLY? Watch for these signs.
If you're hearing it from users first, your monitoring missed something!
When something breaks, here's how to use your logs to hunt it down.
Look at your logs around the time the problem got reported. What was going on right then?
Search for ERROR messages. A lot of the time they flat out tell you what went wrong.
Read the messages right before the error. What was the app trying to do? What led up to it falling over?
If there's a stack trace (that long technical message), it shows exactly where in your code the error happened.
Try to make the error happen again. If you can reproduce it, you can fix it.
You don't want to stare at logs all day (nobody does). Alerts ping you when something needs your attention.
Railway gives you a few ways to get pinged.
Railway's healthcheck setting only checks your app while a new deploy is starting up. It doesn't keep watching after that, so if you want to know when your app stops responding, hook up an outside uptime monitor that pings it every few minutes.
A few habits that make monitoring actually work.
Too many logs and you'll never find the important ones. Stick to what matters.
Use INFO for normal stuff, WARN for things that look off, and ERROR for actual failures.
Don't wait around for users to tell you something's broken. Peek at your logs every so often and catch issues early.
A health check is a simple endpoint (like /health) that returns "OK." Railway can use it during deploys, and an uptime monitoring service can ping it all day to make sure your app is still alive.
That's the Railway chapter, done! Here's what you can do now.
You've got what it takes to move any project from your computer onto the internet. In the next chapter of this module you'll meet Vercel, another popular platform that's especially great for frontend and serverless apps...