Hi Lukas, Thanks for the measurement IDs, they were very helpful. I have found the source of the issue, and am discussing with the team whether this should be fixed in the API or frontend. I will get back to you soon with a fix you can test and then we will roll this out to production. I will at the same time look into rewording the other messages to be a bit clearer. Thanks very much for the detailed information and feedback. Kind regards, Stephen Atlas UI On Fri, 17 Jul 2026 at 11:10, Lukas Tribus <lukas@ltri.eu> wrote:
Hello Stephen,
On Fri, 17 Jul 2026 at 10:06, Stephen Suess <ssuess@ripe.net> wrote:
Hi Lukas,
In my testing this works as expected. Would you mind providing the
original and new measurement IDs, and I will take a look?
Thanks for getting back to me.
I'm trying to mirror the measurement 189412791 with probes:
1011242,1002931,1006278,1004427,1000371,1009376,1000143,25035,22413,12120,22296,17758,54373
As you can see in the video below, measurement 191250776 contains only a single random probe of measurement 189412791, while if I specify them manually (measurement 191250888), it all works (maybe out of 13 I get 12 probes, that's fine).
Video: https://dl.ltri.eu/2026-07-17-10-32-54-ripe-atlas-reuse.mp4
you will usually not get all the probes that were scheduled originally
Ok, got the meaning of the subset text now, perhaps a simplified wording would be "available probes" as opposed to "a set/subset of probes".
While we are at it: Perhaps we can make the error about HTTP Request targeting non-anchors more friendly to the distracted brain that normalizes away everything after "only anchors", or is that just me?
Replace: Only anchors may be targeted
with: Both probes and anchors can execute HTTP measurements. However the HTTP target is limited to anchors.
Best regards,
Lukas