Monitoring & Logs

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.

Why Monitoring Matters#

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.

• Know if your app is running
• See what's happening inside your app
• Catch problems before users notice them
• Understand how people use your app

Understanding Logs#

Logs are messages your app writes about what it's doing. Think of them as your app's diary.

12:00:01 - App started
12:00:02 - Connected to database
12:00:15 - User signed in: [email protected]
12:01:30 - Error: Could not process payment

Every line tells you something that happened. When stuff breaks, logs are your best friend for figuring out why.

Viewing Logs in Railway#

Railway makes your app's logs easy to get to.

Step 1. Open Your Service#

Go to your Railway project and click on your app service.

Step 2. Find the Logs Tab#

Click on "Deployments" or look for a "Logs" section. You might see tabs for different types of logs.

Step 3. View Live Logs#

Railway shows logs in real time. As your app writes new messages, they pop up instantly.

Types of Logs#

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.

Reading Log Messages#

A log message usually has a few parts to it.

2024-01-15 12:00:01 [INFO] User login successful: [email protected]

• Timestamp - When it happened (2024-01-15 12:00:01)
• Level - How important it is (INFO, WARN, ERROR)
• Message - What happened (User login successful)

Log Levels#

Each level means something different.

• DEBUG - Detailed info for developers
• INFO - Normal operations, good to know
• WARN - Something unexpected but not broken
• ERROR - Something failed
• FATAL - The app crashed

When you're hunting down a problem, go straight for the ERROR messages.

Adding Logs to Your Code#

Your app can write its own logs that show up in Railway. Here's how.

JavaScript/Node.js#

console.log('User signed up:', user.email);
console.error('Payment failed:', error.message);

Python#

import sys
 
print('User signed up:', user_email)
print('Payment failed:', str(error), file=sys.stderr)

Anything you print to the console lands in Railway's logs.

Monitoring Resource Usage#

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.

CPU Usage#

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.

Memory Usage#

How much memory your app needs. If it just keeps growing and growing, you might have a memory leak.

Network Traffic#

Data going in and out. Handy for understanding usage patterns.

Finding Resource Metrics#

Step 1. Open Your Service#

Click on your app service in Railway.

Step 2. Look for Metrics#

Find the "Metrics," "Usage," or "Observability" section. You'll see graphs of resource usage over time.

Step 3. Check the Graphs#

Look for spikes and trends. A sudden spike might mean a problem. Steady growth might just mean you're getting more users (nice).

Knowing When Something's Wrong#

How do you catch problems EARLY? Watch for these signs.

In Logs#

• Lots of ERROR messages
• The same error repeating
• Errors you've never seen before
• Stack traces (long technical messages)

In Metrics#

• Memory climbing without going down
• CPU stuck at 100%
• Sudden drops to zero (app crashed)

From Users#

• "The site isn't loading"
• "I can't log in"
• "My data is gone"

If you're hearing it from users first, your monitoring missed something!

Debugging with Logs#

When something breaks, here's how to use your logs to hunt it down.

Step 1. Find When It Broke#

Look at your logs around the time the problem got reported. What was going on right then?

Step 2. Look for Errors#

Search for ERROR messages. A lot of the time they flat out tell you what went wrong.

Step 3. Read the Context#

Read the messages right before the error. What was the app trying to do? What led up to it falling over?

Step 4. Check the Stack Trace#

If there's a stack trace (that long technical message), it shows exactly where in your code the error happened.

Step 5. Reproduce the Problem#

Try to make the error happen again. If you can reproduce it, you can fix it.

Setting Up Alerts#

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.

• Webhooks - Railway sends deploy events (like a failed or crashed deploy) to a URL you pick, and it can post straight into a Slack or Discord channel
• Usage alerts - An email when your spending hits an amount you set
• Monitors - Alerts when CPU, memory, disk or network crosses a line you set (this one needs the Pro plan)

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.

Best Practices#

A few habits that make monitoring actually work.

Log Meaningful Events#

• User actions (sign up, purchase, etc.)
• External service calls (API requests)
• Errors and exceptions
• Performance milestones

Don't Over-Log#

Too many logs and you'll never find the important ones. Stick to what matters.

Use Log Levels Correctly#

Use INFO for normal stuff, WARN for things that look off, and ERROR for actual failures.

Check Logs Regularly#

Don't wait around for users to tell you something's broken. Peek at your logs every so often and catch issues early.

Set Up Health Checks#

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.

TL;DR#

• Logs tell you what's going on inside your running app
• Check your Railway logs regularly to catch problems early
• ERROR messages point at failures that need attention
• Resource metrics (CPU, memory) show how hard your app is working
• Add useful log messages to your code so debugging is easier later
• Never log sensitive info like passwords or keys
• Stack traces show exactly where an error happened in your code

What's Next?#

That's the Railway chapter, done! Here's what you can do now.

• Deploy apps from GitHub
• Add databases
• Manage environment variables
• Connect custom domains
• Monitor your app with logs

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...