<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Synthetic Monitoring on Step Documentation</title>
    <link>https://step.dev/knowledgebase/31/categories/synthetic-monitoring/</link>
    <description>Recent content in Synthetic Monitoring on Step Documentation</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Mon, 17 Mar 2025 14:08:01 +0100</lastBuildDate><atom:link href="https://step.dev/knowledgebase/31/categories/synthetic-monitoring/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Controls</title>
      <link>https://step.dev/knowledgebase/31/userdocs/plans/controls/</link>
      <pubDate>Thu, 23 May 2019 07:00:01 +0100</pubDate>
      
      <guid>https://step.dev/knowledgebase/31/userdocs/plans/controls/</guid>
      <description>Step supports a wide range of so-called controls to build-up complex flows in Plans. The supported controls range from classical control structures (like if blocks, loops, etc) to use-case specific controls like thread groups for load-testing, data-sets, etc. This page provides details about all the controls supported by Step.
General controls Set The Set control allows to define a variable and assign it a value. Variables defined with Set controls can be accessed according to their scope throughout Plans and sub Plans.</description>
    </item>
    
    <item>
      <title>Alerting rules</title>
      <link>https://step.dev/knowledgebase/31/userdocs/alerting-notifications/alerting/</link>
      <pubDate>Thu, 28 Feb 2019 14:08:01 +0100</pubDate>
      
      <guid>https://step.dev/knowledgebase/31/userdocs/alerting-notifications/alerting/</guid>
      <description>Step includes a rule-based mechanism that allows users to define flexible reactions to various events.
In a nutshell, rules allow you to define when to react to specific events (conditions), and how (actions).
The following illustration presents the process in a simplified, informal form:
Events Events are automatically generated by the Step environment and fed into the alerting rules evaluation component. Events contain further details about what happened, in the form of Bindings.</description>
    </item>
    
    <item>
      <title>Alerting and notifications</title>
      <link>https://step.dev/knowledgebase/31/userdocs/alerting-notifications/</link>
      <pubDate>Mon, 17 Mar 2025 14:08:01 +0100</pubDate>
      
      <guid>https://step.dev/knowledgebase/31/userdocs/alerting-notifications/</guid>
      <description>Step includes a flexible mechanism for sending notifications in tandem with the definition of Alerting Rules, allowing to define exactly which events and conditions will result in which notification being sent.</description>
    </item>
    
    <item>
      <title>Schedules</title>
      <link>https://step.dev/knowledgebase/31/userdocs/schedulerview/</link>
      <pubDate>Sun, 29 Nov 2020 14:08:01 +0100</pubDate>
      
      <guid>https://step.dev/knowledgebase/31/userdocs/schedulerview/</guid>
      <description>Schedules allow to configure the recurring or one-time execution of Plans, enabling automated, time-based workflow execution for tasks like synthetic monitoring and beyond.
For the schedules to work correctly, ensure to properly set up the controller’s machine timezone before you start it. Description Let’s describe the Step schedules view: You can access it by clicking “Schedules” on the sidebar menu:
Here is the column description:
Name (1): the name of the schedule.</description>
    </item>
    
    <item>
      <title>Incidents</title>
      <link>https://step.dev/knowledgebase/31/userdocs/incidents/</link>
      <pubDate>Thu, 28 Feb 2019 14:08:01 +0100</pubDate>
      
      <guid>https://step.dev/knowledgebase/31/userdocs/incidents/</guid>
      <description>Incidents are used to be aware of problems in the infrastructure: for instance, Step can periodically run plans which test the behavior of a system. When these plans fail to execute correctly, or (user-defined) assertions concerning the performance do not hold, this constitutes an incident.
Step allows incidents to be automatically created and managed according to user-defined alerting rules. These rules are evaluated in response to various events (most notably after every plan execution).</description>
    </item>
    
    <item>
      <title>Monitoring</title>
      <link>https://step.dev/knowledgebase/31/userdocs/monitoringview/</link>
      <pubDate>Thu, 28 Feb 2019 14:08:01 +0100</pubDate>
      
      <guid>https://step.dev/knowledgebase/31/userdocs/monitoringview/</guid>
      <description>If you’ve purchased the Monitoring package or are running the Premium Enterprise version of Step, you’ll be able to view the status of your Plans scheduled entries. This is very useful for the purpose of building a monitoring dashboard that would be exposed to a support team.
Monitoring View To open it select Reporting -&amp;gt; Monitoring in the sidebar menu.
Name (2): the name of the Scheduler that is monitored - clicking it opens the schedules execution report Plan Link (3) navigate to the connected plan by clicking on the file icon next to the name Cron Expression (4): the expression used in the Plan scheduling entry Last execution (5): the last executions end date-time - clicking on the date navigates to that execution Last status change (6): the last time the Plan execution overall status has changed (from FAILED to PASSED for instance) Status (7): the last Plan execution status Action: execute (8), edit (9), or analyze (10) the Schedule Select which plans to monitor (1) The Monitoring View displays an entry for each Scheduler, so in order to monitor a plan it needs to have a scheduled execution.</description>
    </item>
    
    <item>
      <title>Scheduled execution reporting</title>
      <link>https://step.dev/knowledgebase/31/userdocs/executions/schedule-executions-reporting/</link>
      <pubDate>Thu, 28 Feb 2019 14:08:01 +0100</pubDate>
      
      <guid>https://step.dev/knowledgebase/31/userdocs/executions/schedule-executions-reporting/</guid>
      <description>In this view, you can find reports aggregated across multiple executions of the same schedule. The main purpose of this view is to provide insights into whether scheduled executions have passed or failed over time.
Schedule Name – The name of the scheduled task. Use quick-actions to configure the associated plan or schedule. Last Execution – The most recent time the schedule was executed and its result (pass/fail). The settings for automatic refresh and the time range to be shown.</description>
    </item>
    
  </channel>
</rss>
