Manage monitors

edit

After you’ve created a synthetic monitor, you’ll need to manage that monitor over time. This might include updating or permanently deleting an existing monitor.

If you’re using Project Monitors, you should also set up a workflow that uses best practices for managing monitors effectively in a production environment.

Update a monitor

edit

You can update a monitor’s configuration, for example, changing the interval at which the monitor runs a test.

You can also update the journey used in a browser monitor. For example, if you update the UI used in your application, you may want to update your journey’s selectors and assertions.

If you set up the monitor using Heartbeat, update the relevant options in the Heartbeat configuration file, and the changes will be reflected in the monitors.

Delete a monitor

edit

Eventually you might want to delete a monitor altogether. For example, if the user journey you were validating no longer exists.

If you set up the monitor using Heartbeat, delete the monitor entry in the heartbeat.yml file.

Alternatively, you can temporarily disable a monitor by updating the monitor’s configuration in your journey’s code or on the Uptime app’s Monitor Management page using the Enabled toggle.

Implement best practices for projects

edit

This is only relevant to monitors created using projects.

After you’ve set up a project, there are some best practices you can implement to manage Project Monitors effectively.

Use version control

edit

First, it’s recommended that you version control all files in Git. If your project is not already in a version controlled directory add it and push it to your Git host.

Set up recommended workflow

edit

While it can be convenient to run the push command directly from your workstation, especially when setting up a new project, it is not recommended for production environments.

Instead, we recommended that you:

  1. Develop and test changes locally.
  2. Create a pull request for all config changes.
  3. Have your CI service automatically verify the PR by running npx @elastic/synthetics .

    Elastic’s synthetics runner can output results in a few different formats, including JSON and JUnit (the standard format supported by most CI platforms).

    If any of your journeys fail, it will yield a non-zero exit code, which most CI systems pick up as a failure by default.

  4. Have a human approve the pull request.
  5. Merge the pull request.
  6. Have your CI service automatically deploy the change by running npx @elastic/synthetics push after changes are merged.

The exact implementation details will depend on the CI system and Git host you use. You can reference the sample GitHub configuration file that is included in the .github directory when you create a new project.