Web Monitoring 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.  

API Monitoring jobs simulate interactions with applications or services from any location. To create a job, see Get Started with API Monitoring.

Support

Web Monitoring jobs support these versions and libraries:

Support TypeDescription
Browser Versions
Python Versions
  • Python 2
  • Python 3
Python Libraries


API Monitoring jobs support Node.js v14 (LTS), and you can import any Node.js modules. Additionally, API Monitoring jobs support these modules:

ModulesVersion
@xmldom/xmldom    

0.7.3

assert   2.0.0
buffer   6.0.3
form-data   4.0.0
got  11.8.2
jose   3.15.4
normalize-url   6.1.0
tunnel   0.0.6
xml-crypto 2.1.3
xml2js  0.4.23
zlib1.0.5

Locations

You can execute Synthetic Monitoring jobs in AppDynamics managed hosted agents or private agents:

AgentsLocation
Hosted Agent

Web Monitoring: 22 locations (AWS and Azure)

API Monitoring: 17 locations (AWS)

Private AgentLocation

Maturity Levels

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.

Maturity LevelDescription
Junior

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.

SeniorThe 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.

Execution Order

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.

QueueJob TypeJob Seniority
High-priorityScheduledSenior
On-demandN/A
Low-priorityScheduledJunior

Execution Cadence

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.

Execution Errors

The following table provides job execution error messages, the cause of the error, and the associated error code. 

Error MessageCause of ErrorError Code
Skipped; still waiting for a previous job executionAn 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.TARDY
Skipped while new capacity is being addedAn 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.TARDY_ONBOARDING
Skipped while new capacity is being addedAn attempt was made to queue a measurement request from a junior job beyond the maximum respective queue capacity.ONBOARDING
Testing location is overloadedAn attempt was made to request measurement from a senior job beyond the maximum respective queue capacity.THROTTLED

Health Rule Violation Events

You can configure health rule violation events, such as triggering an event when a job fails. To set health rule violation events, create an alerting policy for synthetic jobs.

This diagram shows the retest process for a job failure and its triggered events. In this example, Job A is scheduled to run at 10:00 am at a five minute interval. 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".


Immediate retest reruns the job immediately after the first failure. All other retest configurations execute the job as per the configured job schedule.

  1. Job A is executed at 10:00 am
    • If Job A succeeds, then no event/message is generated
    • If Job A fails, then the "Error started" event is generated
  2. Job A is retested immediately at 10.01 am (Previous execution: Job A during execution at 10.00 am, and "Error started" event is generated)

    • If Job A succeeds, then no event/message is generated

    • If Job A fails, then the "Error confirmed after retest” event is generated

  3. Job A is executed at 10:05 am (Previous execution: Job A failed during retest at 10.01 am, and the "Error confirmed after rest" event is generated)

    • If Job A succeeds, then the "Problem ended" event is generated

    • If Job A fails, then the "Error continues” event is generated

  4. Job A is executed at the next scheduled time (Previous execution: Job failed and “Error continues” event is generated)

    • If Job A succeeds, then the "Problem ended" event is generated

    • If Job A fails, then the "Error continues” event is generated

  • If the immediate retest based on availability errors or performance threshold is configured, then the "Error started" event is generated.
  • If the error is confirmed during the retest, then the "Error confirmed" event is triggered. 
  • If the error is not confirmed during the retest, then no event is generated.