Site & API Monitoring

Monitors run your scripts on a regular schedule to make sure your site stays alive and functional.

Monitoring is different from load testing. A monitor runs a script on a schedule with a single bot at a time, while a load test typically runs hundreds or thousands of bots concurrently to see how your site handles the heavy load. Both are important if you’re concerned about your site’s performance and uptime.

Luckily, you can often reuse the same Loadster scripts for both load testing and monitoring! The user journeys and site features that you load test are often the same ones you’ll want to monitor, so in many cases you can use the exact same scripts or copies with minor modifications.

If your monitors detect a problem with the site, Loadster can notify you and your team via your choice of email, SMS, robocalls, and integrations with other tools.

Immediate detection of any site downtime or breakage is critical if you want to maintain high uptime and resolve problems with your site quickly.

Monitor Setup & Configuration

Setting up a monitor involves choosing which of your scripts should run, how often, and from which cloud regions or self-hosted engines.

You can also set thresholds for incident escalation and choose how you’d like to be notified of any incidents.

Creating a monitor

Monitors live within a Loadster project alongside your scripts, scenarios, datasets, and load test reports. To create a new monitor, go to a project and expand the add menu, and select New Monitor.

You’ll need to make up a name for the monitor that’s unique within the project, and designate a script that the monitor will run. If your project doesn’t have any scripts yet, you’ll need to create one first before creating a monitor.

After you create a monitor Loadster will schedule it to run. You should have results from the first monitor cycle shortly!

Editing a monitor script

Each monitor is tied to a script in the same project. It runs that script with every monitor cycle. You can edit the script at any time if you’d like to change the steps that the monitor takes when monitoring your site.

Editing a monitoring script is the same as editing any other script. Just keep in mind that editing a monitor script will also affect any other monitors that might be using the same script, and also any load test scenarios that might reference that script.

While scripts are reusable, you might want to create a dedicated script for each monitor if you’re concerned about edits impacting your load tests and other monitors.

Setting a monitor schedule

By default, newly created monitors start with an hourly schedule. That means the monitor will run your script every hour. You can change the monitor frequency from the monitor configuration bar at the top of the page, ranging from every minute to every day.

Higher frequency monitoring (up to every minute) is best for detecting and responding to problems quickly, but might also impact your fuel usage. You can select different schedules for each monitor. You might want to test the most critical components of your site on a faster schedule while testing less important flows less frequently.

Selecting monitoring locations

A monitor can run from one or more locations. These geographical locations are where the bots running your monitoring scripts are located.

Loadster has monitoring regions on several continents. It’s a good idea to choose a region where most of your customers are located, to make sure your site stays reachable from that region. If you prefer, you can specify multiple regions so your monitors alternate between them from one cycle to the next.

You can also run monitors from a self-hosted Loadster Engine if you want to monitor a site that isn’t publicly accessible or you want to make sure it remains accessible from a very specific location.

If your monitor has multiple locations selected, cycles will alternate between them.

Monitoring alerts and notifications

Each monitor cycle records a status on completion. You can view a history of cycle statuses on the monitor page.

Ideally, the status will be PASS every time, meaning that the script completed successfully and without errors. If the script runs and encounters errors, the cycle status will be FAIL.

If the script can’t run because of a misconfiguration or usage limit or some other reason, you might see a less common status like ERROR or THROTTLED or TIMEOUT. If this happens you can troubleshoot the problem and get more info by visiting the monitor page.

Loadster detects when the monitor’s status changes from PASS to FAIL or vice versa. When a monitor fails that was previously passing, Loadster opens an incident.

By default, an incident is opened after a single failing cycle, and it is resolved after a single passing cycle. You can change this with the Escalate on Failure dropdown. You might want to set it to 2+ cycles to avoid being alerted in the event of a short hiccup, but if every failure is critical you can keep the default setting of 1.

Read more about Incidents & Notifications to customize incident creation and resolution, and control how you will be notified of monitoring incidents.

Tagging monitors

You can optionally apply tags to monitors if you want to group or classify them a certain way. You can make up your own tag names.

Maybe you’ll want to tag them by environment, like production and staging, or you might want to tag them by what component of your site they pertain to, like Website and API.

A monitor can have multiple tags applied to it.

Historical Monitoring Data

Monitors continuously keep track of time periods when the monitor was passing and failing.

You can review this historical monitoring data after the fact to see how your site has performed over time, track uptime and downtime, and investigate any incidents that your monitors have detected.

Reviewing your historical monitoring data

When viewing an individual monitor, you can see that monitor’s historical record of passing and failing cycles in detail.

Monitoring data is also available in aggregate for all your monitors on the centralized Monitoring page.