Create a schedule in the Unity Dashboard

Create scheduled events that fire once, on a recurring cadence, or on a fixed interval using the graphical interface of the Unity Dashboard.

읽는 시간 10분

최근 업데이트: 7일 전

The Unity Dashboard provides a graphical interface for creating schedules. To open the schedules list, select Triggers > Schedules and choose an environment.

A schedule emits a custom event on a set date or a recurring cadence. Any trigger that listens for that event receives the schedule's payload and can filter on it the same way it filters any other event. To view, inspect, or delete schedules after you create them, refer to Manage your schedules.

참고

To create and manage schedules in the Unity Dashboard, you need one of the following roles:

Scheduler Configuration Viewer: View the schedules list and schedule details (
```
scheduler.configs.get
```
,
```
scheduler.configs.list
```
). Every create and delete control is disabled for this role.
Scheduler Configuration Editor: Also create and delete schedules (
```
scheduler.configs.create
```
,
```
scheduler.configs.delete
```
).

Create a schedule

You can't change a schedule after you create it. The schedule is live as soon as you create it, but only fires according to the cadence and firing window you configure.

To create a schedule, select New schedule in the schedules list, or Create your first schedule if the environment has none. Without create access, both buttons are disabled. The create dialog is a two-step wizard: complete the Details step, then the Payload step. Use Back and Next to move between steps, select Documentation to open the Triggers documentation, and select the X in the title bar to close the dialog without creating a schedule.

Details

The Details step names the schedule and defines how it fires. To define the schedule, follow these steps:

In Name, enter a name for the schedule. The name must be unique among existing schedules and can't exceed 255 characters. If a schedule with the same name already exists, an error blocks you from continuing.
In Event name, enter the identifier that triggers listen for. This field autofills from the schedule name as a slug (for example,
```
Weekly Sale
```
becomes
```
weekly-sale
```
) and mirrors the name until you edit it directly. If you reuse an event name that other schedules already use, this schedule emits the same event, so the same triggers fire for it. For more information, refer to Payload versioning.
Under Select the type of schedule, select one of the following options:
- Recurring: Fires repeatedly on a schedule you define.
- Interval: Fires on a fixed period like every 2 weeks.
- One-time: Fires once, at a specific date and time.
In the setup card that appears, configure the schedule for the type you selected:
- For a recurring schedule, refer to Configure a recurring schedule.
- For an interval schedule, refer to Configure an interval schedule.
- For a one-time schedule, refer to Configure a one-time schedule.
Check the Summary card at the bottom of the step, then select Next.

Configure a recurring schedule

A recurring schedule fires on a cadence that you define either with simple controls or with a cron expression. Selecting Recurring reveals the Setup repeat card, which holds the cadence fields and the firing window.

To set the cadence, follow these steps:

In the card header, select Builder to define the cadence with simple controls, or Expression to write your own cron schedule for full control. The card confirms the mode you selected below the toggle.
Set the cadence for the mode you selected:
- Builder: Set Frequency to Hourly, Daily, Weekly, or Monthly. For a weekly frequency, select a Day of week. For a monthly frequency, enter a Day of month between 1 and 31; if you choose day 29, 30, or 31, the schedule skips months that don't have that day, such as February. For any non-hourly frequency, set a Time (UTC). An hourly frequency hides the day and time fields.
- Expression: Enter a five-part cron expression, evaluated in UTC. Use the crontab.guru link for help with cron syntax.
Optionally, set a firing window below the cadence. Refer to Set the firing window.

Configure an interval schedule

An interval schedule fires on a fixed period, such as every 6 hours or every 2 weeks. Use it when the time between fires matters more than the time of day, or to express a cadence that a recurring schedule can't, such as every 2 weeks.

Interval fires happen on UTC-aligned boundaries: exact multiples of the interval measured from a fixed epoch (January 1, 1970 at 12:00 AM UTC), not from when you create the schedule or from its start date. For example, a 1-week interval fires on Thursdays at 12:00 AM UTC, because the epoch fell on a Thursday, and a 6-hour interval fires at 12:00 AM, 6:00 AM, 12:00 PM, and 6:00 PM UTC.

Selecting Interval reveals the Setup repeat card. To set the interval, follow these steps:

In Every, enter the number of units in one interval. The minimum is 1, and invalid input resets to 1 when you leave the field. If the field is empty or below 1, creation fails with
```
Enter how often this should fire (at least 1)
```
.
In Unit, select the unit of time between fires: Hours, Days, or Weeks. The field's tooltip restates the boundary behavior: The unit of time between fires. Fires land on UTC-aligned boundaries, not a time you pick — the summary below shows the next fire.
Optionally, set a firing window below the interval. Refer to Set the firing window. A start date doesn't change the rhythm; it only delays the first fire to the first UTC-aligned boundary at or after it.

참고

An interval schedule has no time-of-day, day-of-week, or day-of-month picker, because fires align to the epoch rather than to clock times you choose. A start date doesn't set the phase: a 1-week interval that starts on a Monday at 9:00 AM still fires on the next Thursday at 12:00 AM UTC, not on Mondays. To fire on a specific weekday or time, use a recurring schedule instead.

Configure a one-time schedule

A one-time schedule fires once and has no firing window. Selecting One-time reveals the No repeat card, which holds a single Start date field.

Start date reads Start immediately until you change it. If you leave it on that preset, the schedule fires within about a minute of creation. To fire at a moment you choose instead, follow these steps:

Open the Start date dropdown.
Select On a specific date… to open a date-time picker.
Pick a future date and time. To return the field to Start immediately, clear the picked date.

The field's helper text reads Target a start date, and its tooltip explains both options: The UTC date and time this schedule fires, once. Start immediately fires right after creation. The date you pick is in your local time; refer to Understand time zones.

Set the firing window

A firing window limits when a recurring or interval schedule is active. One-time schedules don't have one.

The window fields sit below the cadence in the Setup repeat card, under the note Time window permitted for schedule to work. Leave blank for an unlimited time window. Both fields start on a preset: Start date reads Start immediately, and End date reads Run indefinitely.

To set a bound, follow these steps:

Open the Start date or End date dropdown.
Select On a specific date… to open a date-time picker.
Pick a date and time. To return the field to its preset, clear the picked date.

Each bound is independent and only needs to be in the future when you set it. The following table describes how the bounds control when the schedule is active:

Bounds	Behavior
Neither	Active immediately, until you delete the schedule.
Start date only	Active from the start date, until you delete it.
End date only	Active immediately, until the end date.
Both	Active only within the range.

When you set both bounds, the end must be after the start, or creation fails with

End date must be after the start date

. For a recurring schedule, the window must also close after the schedule's first fire, or creation fails with

End date is before this schedule's first fire, so it would never run

That second check applies only to recurring schedules, because the service rejects such a configuration. An interval schedule whose window closes before its first fire is valid to save, so the Summary card warns you about it instead of blocking creation.

Understand time zones

Date-time pickers display and accept your local time, but the Scheduler service stores every schedule in UTC. When you pick a date, the field's helper text shows the stored value, for example Shown in your local time. Saves as Oct 31, 2026, 12:00 AM UTC.

The recurring Time (UTC) field is the exception: it's an explicit UTC time of day rather than a local time, because cron expressions run on UTC days. The field label states this.

Review the summary

A Summary card at the bottom of the Details step describes the configuration in plain language and updates as you edit the fields. For example, a daily recurring schedule with an end date reads This schedule starts now and runs until Oct 31, 2026, 12:00 AM UTC (80 days). It fires every day at 09:00 AM.

If the cadence and the firing window barely intersect, or never intersect, the card border turns orange and the summary appends one of the following sentences:

With this cadence it fires only once within the window.
With this cadence it never fires within the window.

This warning is advisory and doesn't block creation, because both configurations are valid to save.

Payload

To define the event payload, follow these steps:

Optionally, in Payload, enter a JSON payload to send with the event. The payload must be a JSON object and can't exceed 1 KB. The Dashboard rejects a top-level array or bare value with the error
```
Payload must be a JSON object, not an array or a single value
```
. To pretty-print valid JSON, select Format JSON, aligned to the right of the Payload label. This button is available only when the content is valid JSON.
Select Create.

A success message confirms the schedule is created, and the schedule appears in the list.

Payload versioning

Versioning is automatic and hidden from you. There's no version field, and the

v1

suffix stays hidden wherever versions appear.

Each event name has a single payload version, its

v1

contract, which defines the shape of the payload that triggers receive:

A new event name starts at
```
v1
```
.
Reusing an existing event name makes the new schedule emit that same event, rather than creating a new version. Every schedule that shares an event name feeds the triggers that listen for it, so one trigger can receive events from many schedules.

When you reuse an event name, an informational note on the Details step tells you the event is already in use by other schedules and that triggers listening for it fire for this schedule too.

To publish a different payload shape, use a different event name. Each name has its own

v1

contract.

참고

Each schedule name must be unique, even when several schedules share an event name.

기술 자료

Development

User Acquisition

Monetization

산업 분야