Connect to Monitoring Tools Only Allows .com HTTP Endpoints

I am designing my own monitoring tool for use with the wix “Connect with external tools to monitor your site”. The problem is I can get the endpoint to work if the URL is set to a .com domain but if I try to redirect to the actual URL I have in mind, which ends with .solutions, it rejects the URL.

Please see the attached photo to see where I am talking about. I am currently using a workaround by sending out the requests to my other site that ends with .com then forwarding back to my .solutions site for storage. So I know my endpoint works.

Thanks for the assistance,
Logan

Hey @loganrdavis !

There are some limitation with the Monitoring tool but the extension of .solution is not one of them.

In order to establish the Monitoring tool, the following needs to be applied:

  1. The URL provided needs to be a valid HTTP endpoint (existing site).
  2. The URL provided for the endpoint needs to be different from the site it is established on.
    The reason for that is to prevent logging loops in the site (the essence of the log will trigger a log and so on and on).

I have received the screencast that you’ve shared with support. It seems that the URL that failed to create an endpoint was not existing (or not published) one.

Please try again following the above logic and let me know if it works for you.

Doron.

Hi @doron-alkalay ,

Thank you for your response as it has very relevant information.

I now understand what my issue is. I am trying to log to the same site for which the logs would generate. For testing URLs I was using my secondary site and was able to use it but if I changed it to .solutions as well it would fail, thus leading me to believe it was the extension. I did not realize the tool was actually checking the existence of the URL endpoint I set.

So does it not make since to store logs relative to your own website within the same database the website itself is using? I understand the fear of recursive logging but a function can easily be set to handle errors and not producing logging in the process (ie using try catch blocks). This is what I’m currently doing. I worked around the built in limitation by sending out the log to my other site, loganrdavis.com, then forwarding back the request to laborsaver.solutions, and it works fine without looping logs.

Based on the limitation you described I would either have to use another service to store my logs or store logs for each site on the other site which seems a little counter-intuitive. For now I suppose I’ll do just that however.

Thank you for your time,
Logan