Replit provides three places to view logs: the Console tab for development output, the Shell tab for interactive commands, and the deployment Logs tab for production. The Console shows structured output from the Run button including stdout, stderr, and duration. Deployed apps stream logs to the Logs tab in the Deployments pane. Add structured logging with timestamps using Python's logging module or a Node.js logger like winston for production-grade log management.
View and Stream Real-Time Logs for Your Replit Application
This tutorial explains where logs appear in Replit during development and production, how to add structured logging to your application, and how to use logs to diagnose issues. You will learn the difference between Console and Shell output, how to read deployment logs, and how to set up structured logging with timestamps and severity levels that make debugging production issues much faster.
Prerequisites
- A Replit account (free Starter plan works for development logging)
- A Replit App with a running web application
- Basic familiarity with the Replit workspace (Console, Shell, Preview pane)
- Core or Pro plan required for deployment log viewing
Step-by-step guide
Understand Console vs Shell vs deployment Logs
Understand Console vs Shell vs deployment Logs
Replit has three distinct places where output appears, and each shows different information. The Console tab shows output from the Run button — it displays structured entries with stdout, stderr, execution duration, and status metadata. The Shell tab is an interactive terminal for running commands manually — its output is separate from the Console. The deployment Logs tab (in the Deployments pane) shows output from your production application. Client-side JavaScript logs (from console.log in browser code) do NOT appear in any of these — they only show in the Preview pane's browser DevTools (right-click Preview, Inspect, Console tab).
Expected result: You understand that Console = Run button output, Shell = manual commands, Logs tab = deployed app output, and browser DevTools = client-side JavaScript.
View development logs in the Console
View development logs in the Console
Press the Run button to start your application. All server-side output — print() in Python, console.log() in Node.js — appears in the Console tab. The Console shows each entry with the command that was run, the output text, and whether it went to stdout or stderr. If your app crashes, the error traceback or stack trace appears here. You can scroll through the Console to see historical output from the current session. Output clears when you stop and restart the app.
1# Python — server-side logging visible in Console:2print("Server started on port 3000")3print(f"Received request: {request.path}")45# Node.js — server-side logging visible in Console:6console.log('Server started on port 3000');7console.log(`Received request: ${req.path}`);8console.error('Database connection failed'); // Shows as stderrExpected result: Pressing Run shows your application's output in the Console tab with clear separation between stdout and stderr entries.
Add structured logging with timestamps
Add structured logging with timestamps
Plain print() and console.log() work for quick debugging but become hard to read in production. Add structured logging with timestamps, severity levels, and context information. For Python, use the built-in logging module. For Node.js, use winston or pino. Structured logs make it much easier to filter for errors, trace request flows, and diagnose timing issues in the deployment Logs tab.
1# Python — structured logging:2import logging34logging.basicConfig(5 level=logging.INFO,6 format='%(asctime)s [%(levelname)s] %(name)s: %(message)s',7 datefmt='%Y-%m-%d %H:%M:%S'8)9logger = logging.getLogger('myapp')1011logger.info('Server started on port 3000')12logger.warning('Slow response: 2.5 seconds')13logger.error('Database query failed: connection timeout')1415# Output:16# 2026-03-27 10:30:00 [INFO] myapp: Server started on port 300017# 2026-03-27 10:30:05 [WARNING] myapp: Slow response: 2.5 seconds18# 2026-03-27 10:31:00 [ERROR] myapp: Database query failed: connection timeoutExpected result: Your application output includes timestamps and severity levels, making it easy to filter for errors and trace timing issues.
Add request logging for web applications
Add request logging for web applications
For web applications, log every incoming request with the method, path, status code, and response time. This creates an audit trail that helps you understand traffic patterns and identify slow endpoints. For Flask apps, use the after_request decorator. For Express apps, use middleware. These logs appear in both the Console during development and the deployment Logs tab in production.
1# Python Flask — request logging:2import time3import logging4from flask import Flask, request, g56app = Flask(__name__)7logger = logging.getLogger('myapp')89@app.before_request10def start_timer():11 g.start_time = time.time()1213@app.after_request14def log_request(response):15 duration = (time.time() - g.start_time) * 100016 logger.info(17 f"{request.method} {request.path} → {response.status_code} "18 f"({duration:.0f}ms)"19 )20 return response2122# Output:23# 2026-03-27 10:30:00 [INFO] myapp: GET /api/users → 200 (45ms)24# 2026-03-27 10:30:01 [INFO] myapp: POST /api/login → 401 (120ms)Expected result: Every HTTP request to your server produces a structured log entry with method, path, status code, and response duration.
View production logs in the deployment Logs tab
View production logs in the deployment Logs tab
After deploying your application (Autoscale, Reserved VM, or Scheduled), open the Deployments pane and click the Logs tab. This shows real-time output from your production application including all print(), console.log(), and logging output. Use the Logs tab to verify your app started correctly, monitor for errors, and track request patterns. Logs stream in real time — new entries appear automatically as they are generated. If no logs appear, your app may have crashed during startup; check for missing Secrets or port binding issues.
Expected result: The Logs tab in the Deployments pane shows real-time output from your production application, including structured log entries with timestamps.
Add error alerting to your logs
Add error alerting to your logs
The deployment Logs tab does not send notifications when errors occur. To get alerted about production issues, add error reporting to your logging setup. The simplest approach is to send a webhook to Slack or Discord when a critical error occurs. Wrap your main request handler in a try/except that catches unhandled exceptions and sends an alert before returning an error response. Store the webhook URL in Tools → Secrets.
1import os2import json3import logging4import urllib.request56logger = logging.getLogger('myapp')78def send_alert(message):9 """Send error alert to Slack webhook."""10 webhook_url = os.getenv('SLACK_WEBHOOK_URL')11 if not webhook_url:12 return13 try:14 payload = json.dumps({'text': f':rotating_light: {message}'}).encode()15 req = urllib.request.Request(16 webhook_url,17 data=payload,18 headers={'Content-Type': 'application/json'}19 )20 urllib.request.urlopen(req)21 except Exception as e:22 logger.error(f'Failed to send alert: {e}')2324# Use in error handling:25try:26 result = process_request(data)27except Exception as e:28 logger.exception('Unhandled error in process_request')29 send_alert(f'Production error: {e}')30 return {'error': 'Internal server error'}, 500Expected result: When a critical error occurs in production, an alert is sent to your Slack channel and the error details are logged to the Logs tab.
Complete working example
1# main.py — Flask app with comprehensive logging for Replit2import os3import time4import json5import logging6import urllib.request7from flask import Flask, request, g, jsonify89# Configure structured logging10logging.basicConfig(11 level=logging.INFO,12 format='%(asctime)s [%(levelname)s] %(name)s: %(message)s',13 datefmt='%Y-%m-%d %H:%M:%S'14)15logger = logging.getLogger('myapp')1617app = Flask(__name__)181920def send_alert(message):21 """Send error notification to Slack."""22 webhook_url = os.getenv('SLACK_WEBHOOK_URL')23 if not webhook_url:24 return25 try:26 payload = json.dumps({'text': message}).encode()27 req = urllib.request.Request(28 webhook_url, data=payload,29 headers={'Content-Type': 'application/json'}30 )31 urllib.request.urlopen(req)32 except Exception as e:33 logger.error(f'Alert delivery failed: {e}')343536@app.before_request37def before_request():38 g.start_time = time.time()394041@app.after_request42def after_request(response):43 duration = (time.time() - g.start_time) * 100044 logger.info(45 f"{request.method} {request.path} "46 f"→ {response.status_code} ({duration:.0f}ms)"47 )48 return response495051@app.errorhandler(Exception)52def handle_exception(e):53 logger.exception('Unhandled exception')54 send_alert(f'Production error: {type(e).__name__}: {e}')55 return jsonify({'error': 'Internal server error'}), 500565758@app.route('/')59def index():60 return jsonify({'status': 'healthy', 'message': 'App is running'})616263@app.route('/api/data')64def get_data():65 logger.info('Processing data request')66 return jsonify({'items': [1, 2, 3]})676869if __name__ == '__main__':70 port = int(os.getenv('PORT', 5000))71 logger.info(f'Starting server on 0.0.0.0:{port}')72 app.run(host='0.0.0.0', port=port)Common mistakes when viewing real-time logs in Replit
Why it's a problem: Expecting browser-side console.log() to appear in Replit's Console tab
How to avoid: Client-side JavaScript logs only appear in the Preview pane's browser DevTools. Right-click the Preview, select Inspect, and open the Console tab there.
Why it's a problem: Not checking the deployment Logs tab after deploying, missing startup errors
How to avoid: Always open the Logs tab in the Deployments pane after deploying. Startup errors (missing Secrets, port binding failures) appear here within the first few seconds.
Why it's a problem: Using DEBUG logging level in production, flooding the Logs tab with noise
How to avoid: Set logging level to WARNING or INFO in production. Use DEBUG only for active troubleshooting sessions.
Why it's a problem: Not setting PYTHONUNBUFFERED=1, causing Python logs to appear delayed or not at all
How to avoid: Add PYTHONUNBUFFERED=1 to [run.env] in your .replit file. Without it, Python buffers stdout and logs may appear late or not at all in the Console.
Best practices
- Use structured logging with timestamps and severity levels instead of plain print() or console.log()
- Log every incoming HTTP request with method, path, status code, and response time
- Set logging level to WARNING or ERROR in production to reduce noise
- Add error alerting (Slack webhook, email) since the Logs tab does not send failure notifications
- Check the deployment Logs tab after every new deployment to verify the app started correctly
- Remember that client-side console.log() only appears in Preview DevTools, not in the Console tab
- Store webhook URLs and API keys for logging services in Tools → Secrets, not in source code
- Log enough context to reproduce issues — include request parameters, user IDs, and timestamps
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I have a Flask app deployed on Replit. How do I set up structured logging with timestamps, log every HTTP request, and send error alerts to Slack when something goes wrong in production? I need to see logs in both the Console during development and the Logs tab in deployment.
Add structured logging to this Flask app. Use Python's logging module with timestamps and severity levels. Log every HTTP request with method, path, status code, and response time. Add a Slack webhook alert for unhandled exceptions using the SLACK_WEBHOOK_URL secret.
Frequently asked questions
Open the Deployments pane in your workspace and click the Logs tab. This shows real-time output from your production application including all server-side print(), console.log(), and logging module output.
The Console shows output from the Run button with structured entries (command, stdout, stderr, duration). The Shell is an interactive terminal for running ad-hoc commands. They are independent — Shell output does not appear in the Console and vice versa.
Python buffers stdout by default. Add PYTHONUNBUFFERED=1 to [run.env] in your .replit file, or pass the -u flag in your run command: run = 'python -u main.py'. This forces Python to flush output immediately.
The deployment Logs tab in Replit shows a real-time stream without advanced search or filtering as of March 2026. For searchable logs, use structured logging and send output to an external service like Logtail, Papertrail, or Datadog.
No. Replit does not send crash notifications automatically. Add error alerting to your application code using Slack webhooks, email, or a monitoring service. The send_alert function shown in this tutorial is a simple way to get started.
Replit retains recent deployment logs but does not guarantee long-term storage. For audit requirements or historical debugging, add a logging service that retains logs for your desired retention period.
Yes. Ask Agent: 'Add structured logging to this Flask app with timestamps, request logging, and Slack error alerts using the SLACK_WEBHOOK_URL secret.' Agent v4 will add the logging configuration, request middleware, and alert function.
For production applications that need centralized log aggregation, metric dashboards, uptime monitoring, and incident alerting, the RapidDev engineering team can integrate your Replit apps with professional observability platforms tailored to your infrastructure.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation