Scheduler

A Scheduler is a repeating run you register in a Space. When you tie one Script to a run time, the server runs that Script every time that time comes around. For example, in an online clothing store, to run a Script once a day that finds products with zero stock and calls the supplier's ordering channel, you create a Scheduler that points to that Script.

A Scheduler is a sub-resource of Space managed in CMA, and its path is based on /spaces/{spaceId}/schedulers. It has no concept of publishing and no sys.version. Once created, it enters the schedule right away, and updates do not need a version header. Instead, two things set it apart from other resources. The Script it runs cannot be changed after creation, and to create or edit one you need that Script's run permission on top of the Space settings permission. Each run leaves a SchedulerLog; a successful run disappears after 1 hour and a failed run after 3 days.

Resource structure

The following is the response when you create a Scheduler. sys holds identifiers and references, and the body holds the name, the run time, and whether it is on.

{
  "sys": {
    "id": "7kQm2ZbTn4Rc9WvXpL3dHsY6fJ",
    "type": "Scheduler",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "script": { "sys": { "id": "3trmXRMKq7bd0Prbef1NcZ", "type": "Refer", "targetType": "Script" } },
    "createdBy": { "sys": { "id": "9dLmQ2pVnRb8sTfWcXd3LhJ7gK", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-08-26T01:20:07.442Z",
    "updatedBy": { "sys": { "id": "9dLmQ2pVnRb8sTfWcXd3LhJ7gK", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-08-26T01:20:07.442Z"
  },
  "name": "Stock reorder",
  "cronExpression": "0 0 * * *",
  "activated": true
}

Key properties:

• sys.id: The unique identifier of the Scheduler. It goes into {schedulerId} in the single-read, update, and delete paths.
• sys.script: The Script this schedule will run. You can set it only at creation and cannot change it afterward. To run a different Script, create a new Scheduler.
• name: The label shown in the console. It is not used for execution.
• cronExpression: When it runs. It has five fields (minute, hour, day of month, month, day of week) and is interpreted in UTC. See Writing the schedule below.
• activated: Whether it is on. If false, the record is kept but it does not run.

There is no sys.version. Do not send the X-Weegloo-Version header on update requests.

System properties (sys)

space, script, createdBy, and updatedBy come in the Refer shape ({ "sys": { "id", "type": "Refer", "targetType" } }).

Body properties:

Writing the schedule

Write the five fields from left to right in the order minute, hour, day of month, month, day of week. There is no seconds field.

You can use * (all), , (list), - (range), and / (step), and you write the day of week as a number (0-7, where 0 and 7 are Sunday) or a name (SUN-SAT).

All values are interpreted in UTC. You must account for the offset from your local time, and for a time tied to a date or a weekday, that offset can push it across a day boundary.

A value that never fires is not saved. A value that is well-formed but points at a day that never comes, such as 0 0 30 2 * (February 30), is rejected.

Status and constraints

Rules for behavior and permissions:

• You need two permissions together. The role's (SpaceRole) settings must include SETTING_SCHEDULER, and, separately, you must have the Execute permission on the target Script. This is checked not only on create but also on update and partial update. Changing when it runs decides when that Script executes, and turning on something that was off starts its execution. If either one is missing, the request is rejected.
• Execution happens with the permissions of sys.createdBy. A :self filter inside the Script also resolves to that user. Even if a different user makes an edit, the executing identity does not change.
• If the author loses the execute permission, it turns off automatically. At the next run time the server checks, does not run, and drops activated to false. Even if the permission is restored, it does not turn back on automatically.
• There is a limit on the count. The number of Schedulers a single Organization can have is set per plan (Free 1, Basic 5, Pro 30, Enterprise unlimited). Going beyond that limit rejects the create.
• The run count is shared with Script. Each run uses one of the plan's Script execution counts. There is no execution limit dedicated to Scheduler. If that limit is exceeded and the Organization's Script execution is suspended, any Scheduler that comes due afterward does not run and its activated drops to false. In that case one SchedulerLog is left behind with the reason in sys.error. Once that Scheduler is off, it is not scheduled again.
• Missed runs are not made up. Even if a run was skipped, it does not run in a batch later; it resumes from the next scheduled time.
• A Script in use cannot be deleted. Trying to delete a Script that some Scheduler references has that deletion rejected (see Script errors).
• There is no publishing. With no status value or publishing step, it enters the schedule as soon as it is created, and deletion happens immediately with no prior step.

SchedulerLog

Each time a Scheduler runs, one execution record is left behind. It is read-only and has no create, update, or delete endpoints. Its path is /spaces/{spaceId}/schedulers/{schedulerId}/logs.

{
  "sys": {
    "id": "5nRt8YcVm2Qb7WxZpK4dGhJ9sL",
    "type": "SchedulerLog",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "requestId": "3trmXRM8dNvQ2LbYpK7fHsJ3gWc4Rt",
    "success": true,
    "createdBy": { "sys": { "id": "7kQm2ZbTn4Rc9WvXpL3dHsY6fJ", "type": "Refer", "targetType": "Scheduler" } },
    "createdAt": "2026-09-03T00:00:02.503Z",
    "updatedBy": { "sys": { "id": "7kQm2ZbTn4Rc9WvXpL3dHsY6fJ", "type": "Refer", "targetType": "Scheduler" } },
    "updatedAt": "2026-09-03T00:00:02.503Z"
  }
}

All values are inside sys, and there are no body properties. A key with no value is omitted from the response (the example above has no error).

There is no scheduler field. Which Scheduler left the record is pointed to by sys.createdBy, whose targetType is "Scheduler". sys.updatedBy is the same Scheduler.

There are no startedAt, endedAt, or result fields, and no elapsed-time field either. How long a run took and the value the Script returned are in the ScriptLog with the same requestId (sys.durationMs, sys.value, sys.statusCode). Its field structure is covered in Script resource and endpoints.

One run leaves two logs. One is this thin SchedulerLog, and the other is the ScriptLog that holds the run itself (the ScriptLog's sys.trigger points to this Scheduler). The two are tied together by the same requestId.

The record is written once after the run ends and never changes. A successful run disappears after 1 hour, and a failed run after 3 days. No field in the response carries the expiry time; the record disappears when its time comes. For values you need to keep longer than that, save them as Content from inside the Script.

Errors

These are the codes you meet when working with a Scheduler. For codes that are common to every resource, see common errors.

API

The base URL for all the endpoints below is https://cma.weegloo.com/v1, and the Authorization header requires a Bearer token that authenticates to CMA. A Scheduler has no sys.version, so you do not send the X-Weegloo-Version header on update.

Related documents

• Script: The resource a Scheduler runs. Covers the definition structure and the kinds of statement.
• Webhook: The resource that runs a Script on an event rather than on a schedule.
• SpaceRole: The role that holds the SETTING_SCHEDULER settings permission and the Script Execute permission.
• Scheduler concept: What the feature is for and how to work with it in the console.