Skip to main content

​
Viewing Logs

Your first stop when debugging production environments should be the Deployments tab on your environment’s page. This shows the build history for your environment, including whether the build completed or failed.
Deployments tab showing build history
Click into a specific deployment row to access its logs. There are two types:
  • Build Logs — If your deployment’s status is Failed, check these first. They contain output from the Docker image build process and will show you exactly where the build broke.
  • Runtime Logs — If your deployment built successfully but you can’t access it or it’s misbehaving, check these. They contain the live output from your running environment server.
Deployment details showing build and runtime log tabs

​
Common Errors

​
Data in the wrong location

If your environment works locally but fails after deploying, one common source of failure is how your data is referenced. Check for these two things:
  1. You didn’t upload your data to OpenReward. Locally, your files sit next to your code. In production, the environment server reads from /orwd_data/, which is populated from the Files tab on your environment’s page. If you haven’t uploaded your data there, the files simply won’t exist at runtime.
  2. Your code points to the wrong path. Even if your data is uploaded, hardcoded local paths like Path(__file__).parent / "answers.json" won’t resolve to /orwd_data/ in production. Use a path check so your code works in both contexts: 
import os
from pathlib import Path

if os.path.exists("/orwd_data"):
    DATA_PATH = Path("/orwd_data")
else:
    DATA_PATH = Path(__file__).parent

with open(DATA_PATH / "answers.json") as f:
    answers = json.load(f)
See Where Environment Data Lives for the full explanation of how /orwd_data/ works and how to structure your files.

​
Out of memory (OOM) crashes

An error like this indicates your environment container was killed for exceeding its memory limit: 
SessionTerminatedError: Session terminated: 503, message='Pod unavailable:
Container crashed (exit code 137). Check the environment's startup command
and configuration.'
Exit code 137 means the process was killed by the OS, typically due to OOM. Start by diagnosing where the memory pressure is coming from, then work through these options:
  1. Reduce memory usage in your environment code. Look for places where you load large amounts of data into memory at once — for example, reading an entire parquet file with millions of rows. Load only what you need for the current task, or stream data instead of loading it all upfront.
  2. Avoid list_tasks with large task sets. list_tasks loads every task into memory. If you have a large number of tasks, override get_task and num_tasks to use index-based access instead, so only one task is loaded at a time. See Ways to Access Tasks for details.
  3. Increase the memory allocation. If your environment genuinely needs more RAM, you can increase it under Settings > Compute Settings on your environment’s page.
Compute Settings showing CPU and memory options