# Site & API Monitoring > Monitor your site 24/7/365 with Loadster scripts. Bots run on a schedule and alert you if your site goes down or breaks, so you can take action. Source: https://loadster.com/manual/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 performance thresholds 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](https://loadster.com/manual/testing-with-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](https://loadster.com/manual/incidents-and-notifications/) to customize incident creation and resolution, and control how you will be notified of monitoring incidents. ### Performance thresholds You can set performance thresholds on each monitor for Response Time (Average), Response Time (Total), and Cycle Duration. If a monitor cycle falls outside these thresholds — below a minimum or above a maximum — the cycle is treated as a failure even if no other errors were encountered. This is useful for catching performance degradations that don't cause outright errors but still indicate a problem. For example, you might set a maximum average response time threshold so that your monitor fails if your site starts responding significantly slower than normal. ### Maintenance windows If your site has scheduled maintenance or deployments, you can use maintenance windows to pause monitors or mute notifications during those periods. This prevents planned downtime from affecting your uptime statistics or waking up your team unnecessarily. You can link maintenance windows to individual monitors from the monitor configuration page, or manage them in the Monitoring tab of Settings. Read more about [maintenance windows](https://loadster.com/manual/incidents-and-notifications/#maintenance-windows) in the Incidents & Notifications documentation. ### 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. _Figure: The monitoring dashboard filtered by date range_ Normally, the monitoring dashboard will be your starting point when looking to see how all your monitors are running and reviewing your site's uptime. ### Filtering and pinning monitors The monitoring dashboard lists all your monitors, but you can filter them if you only want to see certain monitors together. You can even apply multiple filters at the same time. _Figure: Filtering by multiple criteria on the monitor dashboard_ The supported filters include: * **Filter by project** to see only monitors in a given project. * **Filter by status** to see only monitors with a certain status, like PASS or FAIL. Keep in mind this filter may match different monitors at different times, depending on their current status. * **Filter by tags** allows you to show monitors that you've tagged a certain way. If you find yourself using certain filters frequently, you can pin the filtered view to the sidebar and give it a name, so you can easily view your monitors with the same filters in the future. ### Comparing monitor performance over time When you're looking at an individual monitor, you'll see graphs showing the historical performance and status within a date range. _Figure: Graphs show how an individual monitor has done over a time period_ The height of the bars represents the average response time or page load time of each monitor cycle. Of course, each cycle might be measuring multiple requests, so you'll need to investigate further if you want to see performance at the individual request level, but the height of the bar is an easy way to compare relative performance from one cycle to the next or at different times of day. The color of the bars indicates the monitor status during each time period. You can hover and click on the bars for more information and to jump to cycles in that time range. You can also switch between different graph metrics using the metric selector. In addition to response time, Browser Bot and Playwright monitors can graph page timing metrics including Time to First Byte (TTFB), First Contentful Paint (FCP), Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS). ### Drilling down on monitor cycles Clicking on a bar on the upper graph focuses the lower graph on the cycles in that period. Clicking on an individual cycle brings up that cycle's script run results. Loadster retains each cycle's full script run for several weeks so you can go back and investigate any errors. Along with the script logs, you can look at screenshots when testing with Browser Bots, and drill down to detailed requests and responses when testing with Protocol Bots. The level of detail you get about each completed monitoring cycle is the same as when you play the script yourself in the script editor. ### Viewing monitor logs, timelines, and results When you drill down to an individual monitor cycle you'll be able to see the monitor's logs, just like you saw when playing your script in the script editor. For Protocol Bot scripts, you'll also see a *Results* tab with a tree of requests and responses, which you can use to see exactly what was transmitted between the Protocol Bot and your server. For Browser Bot scripts, you'll see a *Timeline* tab with screenshot tiles representing each action in your script. You can expand these to show full-page screenshots and other information about the monitor cycle, just like you did when creating the script. ## Page Timing Metrics Monitors that use Browser Bot or Playwright scripts automatically collect page timing metrics from each cycle. These metrics give you visibility into your site's real-world rendering performance over time: * **Time to First Byte (TTFB)** — How long the browser waits for the first byte of the response from the server. * **First Contentful Paint (FCP)** — When the browser first renders any text, image, or other content. * **Largest Contentful Paint (LCP)** — When the largest visible content element finishes rendering. This is one of Google's Core Web Vitals. * **Cumulative Layout Shift (CLS)** — A measure of visual stability, tracking how much the page layout shifts unexpectedly during loading. This is also a Core Web Vital. These metrics appear on the monitor overview tiles, in individual cycle details, in the monitor graphs (selectable with the metric dropdown), and in CSV exports. Page timing metrics are collected automatically for Browser Bot and Playwright monitors — no extra configuration is needed. Protocol Bot monitors do not collect page timings since they don't render pages in a browser. ## Weekly Summary Emails Loadster sends a weekly monitoring summary email with an overview of how all your monitors performed over the past week. This is a convenient way to keep a pulse on your site's health without logging in to the dashboard. The summary email includes pass rates, failure counts, and performance trends for each of your active monitors. ## Monitoring Plans & Fuel Loadster monitoring can be done with your choice of pay-as-you-go Loadster Fuel or with a predictable monthly plan, similar to load testing. If you don't have a monitoring subscription your monitors will simply burn a little fuel with each cycle and you can add more fuel when it runs low. ### Monitoring with Loadster Fuel If you don't have a monitoring plan, every time a monitor runs it burns Loadster Fuel. The amount of fuel burned depends on the type and duration of the monitoring script. With each monitoring cycle, Protocol Bot scripts burn fuel at a rate of 1 unit per bot hour and Browser Bot scripts burn fuel at a rate of 4 units per bot hour, just like load tests. However, since monitoring scripts are typically short and run for just a few seconds each cycle, they end up using a tiny fraction of a fuel unit per cycle. You can view your actual fuel consumption for a given date range on your monitoring dashboard or on each individual monitor. Your Billing page also shows a breakdown of monitoring fuel usage by project each month. ### Monitoring with a subscription Some Loadster plans cover monitoring without burning any fuel. When you have an active subscription to one of these plans, any monitors that run within your plan limits are fully covered by the plan and do not consume fuel. Monitoring with a subscription tends to be more predictable and is often more cost-effective than fuel, especially if you have lots of monitors or they run frequently. Please contact [help@loadster.com](mailto:help@loadster.com) if you'd like to inquire about a monitoring subscription or have other questions.