Synthetic monitoring without docker


I wanted to test the synthetic monitoring in my test environment using the documentation found here but I only saw a quickstart for docker. Is it possible to use synthetics without docker?

Best regards

I followed the link in the documentation to this subforum:
Creating a ticket there failed with the following error(translated from german):

The selected tag cannot be used.
An error occured while marking the topic.

After removing the synthetics keyword solved the problem...


Whilst the Docker implementation simplifies dependencies etc., you can try running it outside of Docker as well. If you look here, it shows how you can run an inline style of monitor, from the command line (look at the cat... example).

Similarly, this shows you how to run a suite from the command line.

Thanks for the info about not being able to create this in the synthetics category, we will get that fixed.

1 Like

Solved now. Thanks for reporting.


I have still problems getting it to work running HeartBeat 7.10. According to your documentation I should use type browser:

- type: browser
  id: my-monitor 
  name: My Monitor
  schedule: "@every 1m"
  script: |- 
    step("load homepage", async () => {
        await page.goto('');
    step("hover over products menu", async () => {
        await page.hover('css=[data-nav-item=products]');

If I try this (in a monitors.d file) I get the following error:

- type: browser
  id: app-ui-test
  name: app-ui-test
  schedule: "@every 1m"
  script: |-
    step("Open application", async () => {
      await page.goto('https://myhost:8443/myApp/');

Error creating runner from config: monitor type browser does not exist, valid types are [http synthetics/http icmp synthetics/icmp tcp synthetics/tcp]

Should I use synthetics/http instead or do I have to download a specific heartbeat version?

If I try to run my tests as a test suite like this nothing happens at all(not even a log entry):

- name: myApp
  path: "/logserver/applications/heartbeat-7.10.0-linux-x86_64/monitors.d/app-ui-tests/"
  schedule: "@every 1m"

The directory structure of the app-ui-tests directory looks like this:

- node_modules
  - ...
- package.json
- package-lock.json
- myapp.journey.ts

When running standalone using npx @elastic/synthetics . it works on my windows machine but not on our Linux system because of missing certificates. I found this solution in the playwright github but couldn't find a way to configure this in the elastic synthetics - can you give me a hint?

Best regards

Hello @PaulB-Elastic,

I am sorry to bother you again - could you help me out with the above question as I still didn't get it to work?

Best regards

Hi @Wolfram_Haussig , we currently do not support running synthetics outside of a container. The main reason being that supporting running headless browsers on multiple operating systems, with different versions of node, graphics libraries etc. would take away from our ability to focus on core features for the product. As you can probably imagine there's a lot that can go wrong here, and we'd like to focus more on getting the docker experience right (which is already complex) without the burden of supporting all those other configurations.

That said, we'd very much like to support running synthetics without docker in the future when the rest of the product is further along. One thing that would help us is if you could tell us why you either cannot or would prefer not to run with Docker?

@Wolfram_Haussig re: certificates this issue here might be a good temporary workaround, it looks looks more promising with agentOptions, used to set custom TLS settings. That said, there's definitely room for improvement on our end.

I've opened synthetics#170 and synthetics#171 to cover enhancements here.

Hello @Andrew_Cholakian1

Maybe I do not understand what HeartBeat does in this case but I would think that if I get the npx @elastic/synthetics . to work on my machine HeartBeat could simply call that and process the output? I am not saying that you have to support that if you are uncomfortable with that(it is still experimental in any case) but it would open this feature for more users.

The main reason is that all our systems are running on baremetal servers so we do not have the experience to use container. If all our applications would be running in a container already we wouldn't have this discussion here but it is hard to argument that we need additional tools "just" to run monitoring software. Another point is that the main part of our servers are managed by a third party so we do not have root access to easily install software. Therefore, we are currently using the tar.gz versions of the Beats which we can use with our limited users.

As synthetics monitoring does not work without containers I will wait for future updates. Thank you for looking this up!

This topic was automatically closed 24 days after the last reply. New replies are no longer allowed.