Create Scheduled & Manual Triggers

Does your CI/CD pipeline run on every push, even when you only want a nightly build? Or worse, do you find yourself manually clicking a button to trigger a deploy because the pipeline has no way to run on demand? This is the classic trigger trap: a pipeline that always runs, but never at the right time. Knowing how to create scheduled and manual pipeline triggers is the difference between a CI/CD setup that runs itself and one that interrupts your team's flow. In this lesson, you'll learn how to control when your pipelines run — so you can automate the routine, and stay in the driver's seat for the exceptional.

The problem this lesson solves

Imagine you have a pipeline that builds and deploys your application. You set it to run on every push to main, but now you need a nightly data sync that should run at 2 AM — and you're tired of manually running it. Or perhaps you need to trigger a rollback to a previous version, but there's no code change involved. Generic push-based triggers can't handle these scenarios. They either run too often (wasting compute, triggering unwanted deployments) or never run at all when you need them. This lesson solves that by introducing two essential trigger types: scheduled triggers (cron-based) and manual triggers (on-demand). You'll learn how to combine them with existing triggers to build a pipeline that responds to events, time, and human intent — precisely when you need it.

Core concept / mental model

Think of your CI/CD pipeline as a machine with an ignition switch. Push-based triggers are like the machine starting automatically when you insert a key (the push). But what if you want the machine to run at a set time every day, like a coffee maker? That's a scheduled trigger — a built-in timer. And what if you need to run the machine with a special input, like a custom test suite? That's a manual trigger — a button you press with specific parameters.

In CI/CD systems, a trigger is a rule that decides when a pipeline starts. Three main types exist:

• Event-based: runs on Git events (push, pull request, tag).
• Scheduled: runs on a cron schedule (e.g., every night at 2 AM).
• Manual: runs when you click a button, often with inputs.

Your pipeline isn't limited to one — you can have multiple triggers for the same pipeline. For example, a CI pipeline runs on every push, but also on a nightly basis for dependency checks. The trigger system is often separated in the pipeline definition — for instance, in GitHub Actions, triggers live in the on: key, while in GitLab CI, they are defined via rules, schedules, and manual actions. The mental model: triggers are the entry points, and they can be combined to match your workflow needs.

How it works step by step

Creating scheduled and manual triggers usually involves these steps:

1. Identify the trigger types you need. Ask: Do I need a nightly job? Do I allow manual runs with parameters?
2. Define the schedule or manual action in your pipeline config.
3. Set up the required secrets/permissions (e.g., a token for manual approval).
4. Test the triggers by either waiting for the schedule or invoking manual run.
5. Monitor runs to ensure they fire as expected.

Scheduled triggers with cron

Cron is a standard syntax for expressing time patterns: minute hour day-of-month month day-of-week. For example, 0 2 * * * means “at 2:00 AM every day”. You'll need to know your CI system's time zone (usually UTC by default).

Manual triggers with inputs

Manual triggers let you run a pipeline on demand, often with input parameters to customize the run. In GitHub Actions, you use workflow_dispatch; in GitLab, you use a pipeline schedule or a manual job with when: manual. The inputs can be strings, numbers, booleans, or choices, and they're passed as environment variables to the pipeline.

Hands-on walkthrough

Let's put this into practice with two examples: first, a scheduled trigger in GitHub Actions; second, a manual trigger with inputs. These are the most common ways to create scheduled and manual pipeline triggers.

Example 1: Scheduled trigger with GitHub Actions

Create a workflow file .github/workflows/nightly.yml:

name: Nightly dependency check

on:
  schedule:
    - cron: '0 2 * * *'  # 2 AM UTC every day

jobs:
  check-deps:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run dependency audit
        run: |
          echo "Running nightly dependency audit..."
          # Your command here, e.g., pip-audit

When you push this file to the default branch, GitHub will create a scheduled trigger. The workflow will run at 2 AM UTC daily. You can see the next scheduled time in the Actions tab.

Example 2: Manual trigger with inputs

Add a manual trigger to the same workflow (or a new one). The workflow_dispatch event lets you trigger it with inputs.

name: Deploy with custom version

on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'Target environment'
        required: true
        default: 'staging'
        type: choice
        options:
          - staging
          - production
      version:
        description: 'Release version to deploy'
        required: true
        type: string

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy
        run: |
          echo "Deploying version ${{ github.event.inputs.version }} to ${{ github.event.inputs.environment }}"
          # Simulate deploy command

After pushing, you'll see a Run workflow button in the Actions tab. Click it, fill in the inputs, and run.

Expected output

When you run the manual workflow, you'll see logs like:

Deploying version v1.2.3 to staging

Compare options / when to choose what

Here's a quick comparison of different trigger types:

Troubleshooting & edge cases

• Scheduled workflows don't run: Check the cron syntax — GitHub uses UTC and only runs on the default branch. Use crontab.guru to validate. Also, if your workflow file has syntax errors, the schedule won't be registered.
• Manual trigger button missing: Make sure workflow_dispatch is under on: in the workflow file. The button only appears after the workflow is on the default branch.
• Inputs not reaching the job: Use github.event.inputs correctly — note that for workflow_dispatch, you access them via github.event.inputs or inputs in newer syntax.
• Cron minutes may be delayed: GitHub Actions schedules are approximate; they can be delayed by a few minutes due to queue load.

What you learned & what's next

You've learned how to create scheduled and manual pipeline triggers, the core concept, how to configure them step by step, and when to choose each type. You can now make your pipelines run on a schedule or on demand, giving you control over automation and intervention. This is a crucial skill for CI/CD foundations — next, you'll explore pipeline approvals and environment gates, where you'll learn to add manual approval steps for production deployments. Keep your trigger knowledge fresh, and you'll be ready to design pipelines that respond to the right events at the right time.