Synthetic jobs are configurable, scheduled tests that mimic end-user actions in remote browsers in supported locations. Synthetic jobs consist of URL measurements or synthetic scripts. To create a job, see Get Started with Browser Synthetic Monitoring.
The table below describes supported versions and libraries for Synthetic Jobs.
For URL measurements and synthetic script jobs, the Synthetic Agent is always executed in isolation within a Docker container. This location is then mapped to the configured browser location. The synthetic script, however, is run on a different machine or location from the configured browser for security reasons. See Synthetic Agent Locations for more details.
When you create a synthetic job, it is added to a queue based on the creation timestamp. Scheduled jobs are assigned a maturity level that influences when they will be executed in the synthetic job queue. The table below describes the two supported maturity levels.
The Junior maturity level consists of synthetic jobs that are created or updated within two hours. Once two hours have passed since the last update or creation of the job, the Junior job maturity level is promoted to Senior maturity level. The promotion from Junior to Senior maturity is only performed only if enough capacity has been allocated. This avoids negatively affecting jobs which are currently executing.
|Senior||The Senior maturity level consists of synthetic jobs that have been created or updated more than two hours ago. Synthetic jobs with Senior maturity level have ample allocated resources to be executed.|
The execution order of synthetic jobs depends on the job priority and the job creation time. Synthetic jobs are only executed if they are in the job queue. Job priority is based on several factors: job type, job maturity, and your Browser Synthetic Monitoring license. The table below shows how the job priority is calculated. The actual job execution order depends on the job priority and job creation timestamp.
Synthetic jobs are only executed if they are in the job queue. If the max job queue size has been reached, however, no additional synthetic jobs will be added to the queue until the queue size decreases. The max queue size is defined by the priority, license, type, and maturity level.
|Queue||Job Type||Job Seniority|
The synthetic job scheduler executes jobs according to the following cron-based expression:
<second> <minute> <hour> <day-of-month> <month> <day-of-week> <year>
When you schedule a job, you choose how frequently the job runs. It is recommended you choose a larger unit of time (hours or days) that can evenly divide into the smaller unit of time (minutes or hours). For example, if a job is scheduled to run every 15 minutes, the job runs four times within the hour. This results in the job consistently repeating every hour without interruption to the schedule.
However, if you schedule a job such that a larger unit of time that does not divide evenly into the smaller unit of time, such as running every 50 minutes, then the job does not run at consistent times. For example, if the first job starts at 7:03, then the job will run at 7:53, 8:03, 8:53, and so on, resulting in a disruption to the schedule.
The following table provides job execution error messages, the cause of the error, and the associated error code.
|Error Message||Cause of Error||Error Code|
|Skipped; still waiting for a previous job execution||An attempt was made to queue a high-priority measurement request from a scheduled job before the previous measurement request from the same job, and location-browser combination has been processed.|
|Skipped while new capacity is being added||An attempt was made to queue a low-priority measurement request from a scheduled job before the previous measurement request from the same job, and location-browser combination has been processed.|
|Skipped while new capacity is being added||An attempt was made to queue a measurement request from a junior job beyond the maximum respective queue capacity.|
|Testing location is overloaded||An attempt was made to request measurement from a senior job beyond the maximum respective queue capacity.|
Health Rule Violation Events
You can configure health rule violation events, such triggering an event when a job fails. To set health rule violation events, create an alerting policy for synthetic jobs.
The diagram below shows the retest process when a job fails, and what events are triggered. In this example, a job is scheduled to run at 10:00 am. If successful, no event or message is triggered; if it fails, "Error started" is triggered and the job retests. If successful, no even or message is triggered; if it fails, "Error started" is triggered and the job retests. If successful, "Problem ended" is triggered; if it fails, "Problem ended" is triggered and the job retests. As long as the job continues to fail, the job will retest every 5 minutes and continue triggering "Error continues."