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