Hey folks, datadog_dave here! 👋 I've been wrestling with a workflow puzzle in Runway that I'm sure some of you have faced, especially coming from an observability background where we automate *everything*.
I love how Runway handles simple, fixed-parameter recurring tasks. But I keep hitting a wall with tasks that are *mostly* the same, but have one or two variables that change each time. For example:
* Running a weekly database report where the `--start-date` and `--end-date` need to shift forward each run.
* Sending a monthly summary Slack message where the channel or the key metric (like error budget remaining) is different.
* My classic: triggering a canary deployment where the target environment or commit SHA changes.
My current "solution" feels clunky: I have a template task, duplicate it, manually edit the one field, and then run it. That's error-prone and doesn't scale.
I've tried a few approaches, but I'm not fully happy with any:
1. **Using Runway's native "Prompt for Input"**: Great for one-offs, but for true recurrence, I want it scheduled and I don't want to be prompted every single time.
2. **Creating a wrapper script** that calculates the dynamic values (e.g., dates) and then calls the main task. This pushes the logic out of Runway.
```bash
#!/bin/bash
# my_wrapper.sh
START_DATE=$(date -d "last monday" +%Y-%m-%d)
END_DATE=$(date -d "last sunday" +%Y-%m-%d)
# Then somehow trigger the Runway task with these params...
```
3. **External scheduler (like cron)** that hits the Runway API with the correct parameters. This works but splits my logic between two systems.
What's the community's best practice here? Is there a native Runway pattern I'm missing, or is the wrapper script approach the way to go? I'd love to see how others have set this up!
Dashboards or it didn't happen.
Hi Dave, I'm a community manager at a mid-sized fintech, and I run about two dozen recurring workflows in prod with similar needs, from daily report generation to staggered deployment rollouts.
The real solution here is parameterization, and I've seen three main ways teams handle it in Runway, each with a different trade-off.
1. **Runway's Scheduled Tasks with Static Overrides**
You can set a schedule directly on a task and override its parameters with static values. This works if your changing variable is predictable, like a date. For monthly reports, I have tasks scheduled on the 1st with a parameter like `report_month: "last_month"` that my script interprets. The hard limit is the value must be pre-defined; you can't compute "yesterday" or fetch a value from an API at schedule time within the task definition itself.
2. **External Scheduler Feeding Dynamic Parameters**
This is what my team moved to. We use our observability stack (a simple cron pod in Kubernetes, but you could use Airflow, Jenkins, even a scheduled Lambda) to trigger the Runway task via its API. The external job calculates the needed values (like the exact date range or commit SHA) and passes them as parameters in the API call. Integration effort is medium: you need to set up the scheduler and manage API credentials. This wins for anything requiring logic, like "skip if holiday" or pulling a value from another system. It adds another moving part to manage.
3. **Runway Task that Calls a Parameterized Script**
We also have tasks that are just a shell step calling a script stored in our repo. The script contains all the dynamic logic. The Runway task is a static shell, but the script it pulls can handle date math, API calls, etc. Deployment effort is higher because your script version and your task definition must stay in sync. This is best when the logic is complex and owned by a specific team. The clear win is testability; you can run the script locally.
4. **The "Prompt for Input" Fallback with Service Accounts**
For tasks that truly need a human to review a calculated parameter before running, we've set up a dedicated service account and scheduled the task to run under it. The prompt appears, but the account is configured to auto-approve after a short delay. It's a niche workaround, but it worked for a compliance report that needed a manager to acknowledge the parameters. The limitation is it still creates a notification burden.
My pick is the external scheduler for your use cases. The database report and canary deployment both need dates and SHAs calculated at runtime, which an external cron job can do easily before hitting Runway's API. If that's too much overhead, then push the logic into a script called by a static Runway task.
To make the call clean, tell us: 1) who needs to be able to modify the schedule or the logic (is it just your team, or do other teams need a UI?), and 2) how critical is auditability of the exact parameter values used for each run?
Keep it real, keep it kind.