---
title: "Activity feed filters, guided IaC migration, cron jobs in the CLI"
date: 2026-10-16T17:07:00.000Z
number: 0312
url: https://railway.com/changelog/2026-10-16-activity-feed-filters
---

# Activity feed filters, guided IaC migration, cron jobs in the CLI

Your project has a lot going on. Your activity feed doesn't need to tell you all of it at once. This week, we're helping you find relevant activity, smoothly move from Config as Code to infrastructure as code, and inspect and trigger cron jobs from your terminal.

Let's get into it! 🚄

# Activity feed filters

[Find the changes that matter to your service](https://cms.railway.com/media/546d5d51-18b4-4295-9c36-f0760b114ca0-activity-feed.mp4)

A busy project can produce a busy feed. Finding one service's changes used to mean scanning activity from the whole environment.

The activity feed now lets you filter by service and activity type. Open it from a service to focus on that service's activity, or choose services in the project feed. Service icons and colors help you recognize which service each event belongs to.

You'll also see activity that wasn't shown in the feed before, including image auto-updates, variable changes, volume operations, and services being added or removed. Filter to the events you care about when you're working out what changed.

Try the filters in your project, and share your feedback on [Central Station](https://station.railway.com/new?type=feedback).

# Guided IaC migration

[ Generate your IaC configuration, then review the switch before applying it.](https://cms.railway.com/media/42b849fd-8beb-4b27-8dfe-2ff2a06b71c8-railway-cac-to-iac-interactive.mp4)

Your move to infrastructure as code starts with the configuration you already have.

The CLI now guides you from `railway.json` or `railway.toml` to an infrastructure as code authoring file. Generating that file and switching services away from Config as Code are separate steps, so writing the configuration doesn't silently change which file your services use.

Run `railway config migrate` for the interactive flow. To write the generated file without switching your services over, use `railway config migrate --apply`. When you're ready, `railway config migrate cutover` lists the affected services, warns about redeployments and inherited environments, and saves the previous config-file paths before making the switch.

`railway config migrate status` shows where each service stands. If you need to return to the previous config-file paths, `railway config migrate undo` restores them from that saved snapshot.

Update with `railway upgrade`, check out the [IaC documentation](https://docs.railway.com/infrastructure-as-code), and share your migration feedback on [Central Station](https://station.railway.com/new?type=feedback).

# Cron jobs in the CLI

[Check recent cron runs and trigger a job from your terminal](https://cms.railway.com/media/7f9ef11b-ec03-46c8-b04c-e5b7de3e84f4-railway-cron.mp4)

Check on your cron jobs and run them on demand, right from your terminal.

`railway cron list` shows recent executions with their status, start time, and duration, alongside the schedule and next run. It also prints a ready-to-run logs command for the latest completed execution, so you can inspect that run without working out its time window.

When you need a job to run off-schedule, use `railway cron run`. The command asks for confirmation, then enqueues an execution. Both commands use your linked service by default, or accept `--service` and `--environment` to target another cron service.

These commands bring the dashboard's Cron Runs workflow into your terminal. Your coding agent can use the same commands, too. Ask it to check whether your nightly sync succeeded, pull logs from a failed run, or trigger your cleanup job. 

Update with `railway upgrade`, read the [cron command reference](https://docs.railway.com/cli/cron), and tell us what you think on [Central Station](https://station.railway.com/new?type=feedback).

# Fixes and improvements

- We improved CDN settings so changes appear in your environment's pending changes for review before applying them. Previously, changing a CDN setting applied it immediately. Cache purges remain immediate.
- We shipped CDN configuration in infrastructure as code. You can define caching settings in your authoring file and review them with `railway config plan`, instead of managing them separately.
- We improved function support in `railway config pull` and `railway config plan`. Pull exports readable source files, and plan shows source-code diffs instead of encoded start-command strings.
- We fixed Config as Code migration to preserve build settings and correctly handle services that share a configuration file. Previously, migrations could omit build settings, drop services sharing a file, or include unrelated files from other projects in a monorepo.