- ripe-atlas - mailman.ripe.net

Kind request for credits
by Khodor SAFA 29 Jun '26

29 Jun '26

Hello everyone, I hope this message finds you well. I have been advised by the RIPE Atlas team to contact this mailing list for my request of credits. Any number you can provide could be useful for me, at least to begin getting familiarised with the platform. Thank you very much in advance!

3 4

Announce: upcoming changes in historical data access
by Robert Kisteleki 23 Jun '26

23 Jun '26

Dear RIPE Atlas users, We'd like to inform you about an upcoming change affecting downloads of large, historical results. As of today, one can ask the RIPE Atlas API to supply results of measurements without time boundaries, as in "give me all the data you have for this measurement". That's fine for results of one-off measurements because those are always relatively small. However for periodic measurements this is mostly harmful as it results in possibly huge amounts of data, as such it's often aborted, and incurs costs on both parties. We plan to enforce time limit parameters, where the query for results will have to specify a start and and end time and the interval spans at most a week. Scripts that intend to download results for a wide time interval will need to loop through the interval in chunks (perhaps per day, ideally aligned to UTC midnight to be the most efficient). UI functionality will not be affected. We intend to apply this change around the first week of August. Regards, Robert Kisteleki, for the RIPE Atlas team

1 0

Re: Atlas UI updates for 2026-06-09
by ripe＠brite.cz 16 Jun '26

16 Jun '26

Could you please make the "Passkey" type of login method as default (when configured), instead of "Authenticator application". Or at least have the "Select login method" as default or let the user choose the default once and make it remember. In fact, retyping number from Authenticator application that is the least comfortable way of login. Also would be great if the login is remembered across multiple days, so no login is needed every single time. Thanks Jiri ------------------------------------------------------------------------------------------------------------- út 9. 6. 2026 v 10:41 odesílatel Stephen Suess <ssuess(a)ripe.net> napsal: Hello Atlas community, We have just pushed some new updates to the UI. Among the highlights: - Well-known measurements: In addition to Google, Facebook and Wikipedia, we have added Akamai, Amazon, Azure, Cloudflare, Fastly, Github, Instagram, LinkedIn, Netflix, Reddit, X and Youtube. We have also added the ability to set your choices on the results tab of the probe detail pages, share links to these selections, and save your preferences so that you always see your preferred selections when visiting these pages. In addition, these measurements have been added to the Well-known RTT map at https://atlas.ripe.net/maps/well-known - Probe connectivity use case enhancements: You can now select "All Probes" (careful, it may take some time to load) as well as a checkbox to separate probes by controller to see connections by controller visualised in the main graph. You can see the full list of what has changed in the release notes: https://atlas.ripe.net/docs/releases/website_index/2026-06-09 As always, we welcome your feedback and would love to know what you think. Kind regards, Stephen Atlas UI ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

3 2

Probe connected, but data upload seems to fail with 429, and high bitrate bursts
by ripe＠nurfuerspam.de 10 Jun '26

10 Jun '26

Hi, I have a software probe that since a few days only is sending very short traffic bursts at very high bitrates (for a probe), amounting to a 5 minute bitrate average nearing 1 Mbit/s. I _think_ this _may_ have started on or around 2026-06-07, but I don't have detailed logs going back that far anymore (destroyed the container the probe was originally running in, see below, several times in the course of troubleshooting this without saving the logs :-() When looking into the current logs, I see (as per my understanding) that the POST upload of the measurement data apparently fails with a 429 error, or an occasional "httppost: error reading from server: Connection reset by peer". See below for two instances from the log. Originally, the probe was running in a container (like most of my other probes as well without issues), then version 5100 natively on Debian 12 x86_64 VPS, just upgraded to 5120 - same result. Probe ID 1009529. Any thoughts? Thanks! Cheers, R. Jun 10 18:59:24 vps-cbf1 ripe-atlas[173212]: total size in dir: 6254 Jun 10 18:59:24 vps-cbf1 ripe-atlas[173212]: httppost: before getaddrinfo Jun 10 18:59:24 vps-cbf1 ripe-atlas[173212]: httppost: before connect Jun 10 18:59:24 vps-cbf1 ripe-atlas[173212]: httppost: sending request Jun 10 18:59:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/1' Jun 10 18:59:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/5' Jun 10 18:59:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/2' Jun 10 18:59:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/0' Jun 10 18:59:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/3' Jun 10 18:59:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/6' Jun 10 18:59:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/7' Jun 10 18:59:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/8' Jun 10 18:59:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/4' Jun 10 18:59:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/9' Jun 10 18:59:24 vps-cbf1 ripe-atlas[173212]: httppost: getting result Jun 10 18:59:25 vps-cbf1 ripe-atlas[173212]: httppost: POST command failed: '429 ' Jun 10 18:59:25 vps-cbf1 ripe-atlas[173212]: httppost: leaving with error Jun 10 18:59:25 vps-cbf1 ripe-atlas[173212]: ooqd: httppost failed with 1 Jun 10 18:57:24 vps-cbf1 ripe-atlas[173212]: total size in dir: 6254 Jun 10 18:57:24 vps-cbf1 ripe-atlas[173212]: httppost: before getaddrinfo Jun 10 18:57:24 vps-cbf1 ripe-atlas[173212]: httppost: before connect Jun 10 18:57:24 vps-cbf1 ripe-atlas[173212]: httppost: sending request Jun 10 18:57:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/1' Jun 10 18:57:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/5' Jun 10 18:57:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/2' Jun 10 18:57:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/0' Jun 10 18:57:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/3' Jun 10 18:57:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/6' Jun 10 18:57:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/7' Jun 10 18:57:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/8' Jun 10 18:57:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/4' Jun 10 18:57:24 vps-cbf1 ripe-atlas[173212]: posting file '/var/spool/ripe-atlas/data/out/ooq/9' Jun 10 18:57:24 vps-cbf1 ripe-atlas[173212]: httppost: getting result Jun 10 18:57:25 vps-cbf1 ripe-atlas[173212]: httppost: error reading from server: Connection reset by peer Jun 10 18:57:25 vps-cbf1 ripe-atlas[173212]: httppost: leaving with error Jun 10 18:57:25 vps-cbf1 ripe-atlas[173212]: ooqd: httppost failed with 1

1 1

Atlas UI updates for 2026-06-09
by Stephen Suess 10 Jun '26

10 Jun '26

Hello Atlas community, We have just pushed some new updates to the UI. Among the highlights: - Well-known measurements: In addition to Google, Facebook and Wikipedia, we have added Akamai, Amazon, Azure, Cloudflare, Fastly, Github, Instagram, LinkedIn, Netflix, Reddit, X and Youtube. We have also added the ability to set your choices on the results tab of the probe detail pages, share links to these selections, and save your preferences so that you always see your preferred selections when visiting these pages. In addition, these measurements have been added to the Well-known RTT map at https://atlas.ripe.net/maps/well-known - Probe connectivity use case enhancements: You can now select "All Probes" (careful, it may take some time to load) as well as a checkbox to separate probes by controller to see connections by controller visualised in the main graph. You can see the full list of what has changed in the release notes: https://atlas.ripe.net/docs/releases/website_index/2026-06-09 As always, we welcome your feedback and would love to know what you think. Kind regards, Stephen Atlas UI

5 7

Reporting incorrect location of an anchor
by Serhii Timofieiev 08 Jun '26

08 Jun '26

Is it possible to report RIPE Atlas anchor having an incorrect location?

3 2

Issues with software probes connections
by Robert Kisteleki 08 Jun '26

08 Jun '26

Dear software probe hosts, Around Friday afternoon we started experiencing an issue where software probes that disconnected for any reason were not allowed to connect again. Over time this caused a gradual decrease in the number of connected probes, up to 20% of software proves or about 10% of the total probe population. We identified the root cause to be a delay of processing of internal control messages. We executed ad-hoc measures that allowed most probes to temporarily connect again, and we are currently working on a proper solution. I'll post an update once we this solution in place. Regards, Robert Kisteleki

1 0

Re: Your probe 1008669 has disconnected
by Marek Küthe 07 Jun '26

07 Jun '26

Hello, My probe has disconnected. Could someone take a look at this? The message in the log is as follows: ``` Jun 06 00:12:48 laplace ripe-atlas[113935]: condmv: not moving, destination '/var/spool/ripe-atlas/data/out/simpleping' exists Jun 06 00:12:48 laplace ripe-atlas[113934]: condmv: not moving, destination '/var/spool/ripe-atlas/data/out/v6addr.txt' exists Jun 06 00:12:48 laplace ripe-atlas[113915]: reg server asked us to wait or there was an error. REG_WAIT_UNTIL 1780697679 Jun 06 00:12:47 laplace ripe-atlas[113915]: ssh -p 443 atlas(a)193.0.19.246 INIT Jun 06 00:12:47 laplace ripe-atlas[113915]: REGHOSTS reg03.atlas.ripe.net 193.0.19.246 2001:67c:2e8:11::c100:13f6 reg04.atlas.ripe.net 193.0.19.247 2001:67c:2e8:11::c100:13f7 Jun 06 00:12:47 laplace ripe-atlas[113915]: REG_WAIT_UNTIL expired go re-reg 1780697510 now 1780697567 Jun 06 00:12:47 laplace ripe-atlas[113915]: there is WAIT, REG_WAIT_UNTIL , now is 1780697567 Jun 06 00:12:47 laplace ripe-atlas[113915]: ATLAS registration starting Jun 06 00:12:47 laplace ripe-atlas[1356]: start reg Jun 06 00:12:47 laplace ripe-atlas[1356]: Ping works Jun 06 00:12:44 laplace ripe-atlas[1356]: /run/ripe-atlas/status/reginit.vol does not exist try new reg Jun 06 00:12:44 laplace ripe-atlas[1356]: RESULT 9006 done 1780697564 901b0e4bf9d8 no reginit.vol start registration ``` I've attached the last 200 lines of the log. Best regards, Marek Küthe On Fri, 05 Jun 2026 17:00:00 +0000 "RIPE Atlas" <atlas+e76c0ca5(a)ripe.net> wrote: > ###Probe 1008669 is disconnected () > > > Marek Küthe, > > > > Your probe 1008669 has been disconnected from the RIPE Atlas infrastructure since 2026-06-05 16:25:47 UTC. > > You may be able to learn more about the possible cause from the "Status" tab on your probe's information page: > > https://atlas.ripe.net/probes/1008669/#!tab-status > > Probes are tagged with suspected problems every four hours, so if there is nothing listed under the Status tab and your probe has just gone offline, please check back in a few hours, as more information may be available. > > If you need further assistance or have any questions, please contact us at atlas(a)ripe.net. > > > Best regards, > The RIPE Atlas Team > > **RIPE NCC** > > Stationsplein 11, 1012 AB, Amsterdam > > This email was sent to m.k(a)mk16.de > > You've received this email because you are registered as a RIPE Atlas probe host. -- Marek Küthe m.k(a)mk16.de er/ihm he/him

5 9

And another probe disconnected
by Ernst J. Oud 07 Jun '26

07 Jun '26

Number 4 of 11 is down… Ouch. Ernst

2 2

Disconnected probes
by Ernst J. Oud 06 Jun '26

06 Jun '26

The controller with a problem appears to be ctr-dub-sw01 And reg server reg03 and/or reg04. Met vriendelijke groet, Ernst J. Oud

1 0

Re: Your probe 1008669 has disconnected
by Ernst J. Oud 06 Jun '26

06 Jun '26

Yes, my three software probes that are down are on 5G connections that have a forced renew of their IP address every 24 hours. The controller in Dublin I believe has some fault. Hope RIPE corrects this asap. Met vriendelijke groet, Ernst J. Oud Met vriendelijke groet, Ernst J. Oud > On 6 Jun 2026, at 17:11, via ripe-atlas <ripe-atlas(a)ripe.net> wrote: > > Hi again, > > My number keeps going up. Looks like whenever a probe gets disconnected for some other reason, it is not able to connect back to the system. > > And my earlier count was too low already. It seems e-mail notifications aren't sent reliably. At least I didn't get one for some probes that are definitely down longer than the timeout configured (mostly default of 30 minutes). > > Cheers, > > R. > >> On 6/6/26 17:06, Ernst J. Oud wrote: >> Hi, >> Same here. Three of my software probes have disconnected this morning. Nothing wrong with internet at those locations. One of these locations also has a hardware probe that runs fine. >> In the logs it says: >> —- >> /var/atlas-probe/status/reginit.vol does not exist try new reg >> Ping failed >> start reg >> ATLAS registration starting >> there is WAIT, REG_WAIT_UNTIL , now is 1780758142 >> REG_WAIT_UNTIL expired go re-reg 1780758077 now 1780758142 >> REGHOSTS reg03.atlas.ripe.net 193.0.19.246 2001:67c:2e8:11::c100:13f6 reg04.atlas.ripe.net 193.0.19.247 2001:67c:2e8:11::c100:13f7 >> ssh -p 443 atlas@2001:67c:2e8:11::c100:13f6 INIT >> 255 REGINIT exit with error >> condmv: not moving, destination '/var/atlas-probe/data/out/v6addr.txt' exists >> condmv: not moving, destination '/var/atlas-probe/data/out/simpleping' exists >> —- >> Something definitely wrong with the controller infra! >> Regards, >> Ernst J. Oud >>>> On 6 Jun 2026, at 14:16, via ripe-atlas <ripe-atlas(a)ripe.net> wrote: >>> Hi, >>> Same thing is affecting five of my probes since yesterday, also with repeated messages of being asked to wait, or there having been an error: >>> 2026-06-06T12:13:24.673341015Z reg server asked us to wait or there was an error. REG_WAIT_UNTIL 1780748131 >>> I understand that you "updated [y]our controllers so all probes disconnected for a short while" yesterday, but that is now more than a day ago? >>> Thanks! >>> Kind regards, >>> R. >>>> On 6/6/26 00:14, Marek Küthe via ripe-atlas wrote: >>>> Hello, >>>> My probe has disconnected. Could someone take a look at this? >>>> The message in the log is as follows: >>>> ``` >>>> Jun 06 00:12:48 laplace ripe-atlas[113935]: condmv: not moving, destination '/var/spool/ripe-atlas/data/out/

1 0

Controller error?
by Ernst J. Oud 06 Jun '26

06 Jun '26

And to add insult to injury… three probes down, only one gave me a status message to that effect. So never received a notification that the other two were down too. The change to the new status email template introduced some error perhaps? Regards, Ernst J. Oud

1 0

Global timeout event root DNS
by Jesse Prins 06 Jun '26

06 Jun '26

Hey all! For the final research project for my bachelor I am researching timeouts involving the Root DNS servers using RIPE atlas measurements. In my research I stumbled upon (in my opinion) a weird event that I can’t find any causes for. On the 23rd of December there was a spike (ranging from 10% - 60% depending on the server) in timeouts involving all root servers except F, G and H which don’t show any spike at all (see https://rootviz.sidnlabs.nl/public-dashboards/f81c02c68d7a4986ba1674fd7eb87…) My main question is if there were any problems with RIPE atlas itself around this time (causing an artifical spike)? and if not: Does anyone know what could have caused such a global spike in timeouts? Thanks in advance. Kind regards, Jesse Prins

1 0

Probe disconnect and reconnect emails with missing data
by Johan ter Beest 05 Jun '26

05 Jun '26

Hello Atlas friends, We recently changed the templates for the probe disconnect and probe reconnect messages. Unfortunately, there was a small mistake in the message parameters causing the email to appear essentially empty (no probe ID, no since, no probe description). This error has been fixed now. Apologies for the mistake, Kind regards, Johan ter Beest RIPE Atlas Team

1 0

Spam?
by Ernst J. Oud 05 Jun '26

05 Jun '26

Hi, Just received an email from atlas+e76c0ca5(a)ripe.net saying: —- Probe is disconnected () Ernst J., Your probe has been disconnected from the RIPE Atlas infrastructure since 2026-06-05 09:23:26 UTC. —- As shown above, no probe ID is mentioned and the sender’s email address is a bit weird since normal status messages come from no-reply(a)ripe.net. Also all my probes are functional. A test run at RIPE gone wrong? Regards, Ernst J. Oud

2 1

Atlas UI updates for 2026-05-27
by Stephen Suess 27 May '26

27 May '26

Hello Atlas friends, We have just updated the UI with a new and improved LatencyMON, as well as various other fixes and changes that you can read about here: https://atlas.ripe.net/docs/releases/website_index/2026-05-27 Please let us know if you have any questions or feedback. Kind regards, Stephen Atlas UI

1 0

Controller ctr-dub-sw01 problem?
by Ernst J. Oud 17 May '26

17 May '26

My software probe 1004467 disconnected from controller last ctr-dub-sw01 night. The CentOS VM it is running on has no problems. It has internet access. I rebooted it but that didn’t change anything. Problem with this controller not accepting connection requests? Other probes on this controller still work.. Regards, Ernst J. Oud

1 2

probe migration
by Marco Moock 17 May '26

17 May '26

Hello! In case of a hardware switch, is it reasonable to migrate the software probe to the new machine? In cases of that, which files need to be migrated? -- kind regards Marco Muell und Spam bitte an abfalleimer2000(a)stinkedores.dorfdsl.de

2 1

RIPE Atlas Credit Request — Student at UCLA conducting CGN measurement research
by Sarah 15 May '26

15 May '26

Hi all, My name is Sarah Zhao and I am a Computer Science and Engineering student at UCLA. I am currently conducting undergraduate research in computer networking at the UCLA Connection Lab under the mentorship of Professor Leonard Kleinrock. As part of my research I am studying the deployment and impact of Carrier-Grade NAT (CGN) at Internet scale. I plan to use RIPE Atlas traceroute measurements to detect CGN presence via 100.64.0.0/10 address leakage in hop paths, and TCP connect measurements to probe inbound reachability from CGN and non-CGN ASes as comparative vantage points. I need geographically diverse probes across networks in developing regions where CGN deployment is most concentrated. As a new user I have no credits and kindly ask for a donation to get started. An allocation of 200,000 credits would cover my planned measurement phases. My RIPE Atlas account is registered under: sarahzhao01(a)gmail.com I am very eager to share my findings with the community. Thank you in advance for any help! Best, Sarah Zhao UCLA Computer Science

6 7

Rollout of software probe anti farming measures
by Francesco Iannuzzelli 12 May '26

12 May '26

Dear RIPE Atlas users, Some of you may remember earlier discussions about this topic. We’re now ready to enable a feature to address this issue. Supporting each probe requires resources from the system; at the same time having too many probes in the same network and location does not provide much new information (that is, more probes in the same location or network would provide similar measurement results). Therefore we have controls in place to limit the amount of /software/ probes that are connecting from particular networks: 1. Each probe host can connect up to 2 software probes from the same IP address. 2. Each probe host can connect up to 4 software probes from the same IP prefix (as seen in BGP). 3. At most 32 (or 64) probes from the same IPv4 (or IPv6) prefix (as seen in BGP), regardless of the host. Software probes that connect from networks beyond these limits will not be allowed to connect, unless and until other software probes drop out. Note that we may also adjust the particular maximums over time. We realise that in some cases multiple probes belonging to the same user can come seemingly from the same network, violating rule 2 (mostly), yet they arguably still provide enough value for the community. This may be for example because they are in fact geographically widely distributed. In such a case the host can reach out to us via atlas(a)ripe.net with an explanation and we will consider relaxing this limit. While in the past we observed surprising corner cases, the particular limits described above are set partially taking into account the current software deployment. Therefore only a handful of probe hosts should be impacted by this (as I write this, 71 probes from 13 hosts). As I mentioned above, we’re open to adjust the limits if needed. Regards, Francesco Iannuzzelli

5 5

New LatencyMON in beta
by Stephen Suess 11 May '26

11 May '26

Hello Atlas friends, We are currently in beta testing for a modern replacement of LatencyMON. Our plan is to roll this out fairly soon, but we wanted to show it to the community first and ask for your feedback on it. Here are some of the differences from the old version: - Complete migration to Vue3/Quasar code like the rest of Atlas (no legacy jquery, requirejs, backbone, or any of that) - UI refresh and cleanup - New toggle to add groups by distance from target (in addition to the default of countries with greatest number of probes) - Showing min/med/max values (with toggle to only show min) - Groups can be split into single probe charts with button click - Link out to msm ID - Now linking to latencymon from dns/tls/http (as well as ping/traceroute) with better support for these - Fullscreen zoom - Ability to load data outside routequake (aggregated API used for latencymon) limits from regular (non aggregated) results (limit to 10k samples for now for performance) - Areas with packet loss now opacity scaled for better visibility (with tooltip note to zoom in for full data when not in full resolution) - Charts can be drag resized You can check out the new LatencyMON on our beta-ui site (https://beta-ui.atlas.ripe.net/) by going to the link at the top of any measurement detail page (for any periodic measurement). Here is an example: https://beta-ui.atlas.ripe.net/latencymon/93652781 We welcome your feedback and look forward to hearing from you. Kind regards, Stephen Atlas UI

1 0

Our website Bollywood.com is blocked, want to run probes
by Kipling Buis 11 May '26

11 May '26

Dear Members, I am system admin for website Bollywood.com. We are located in California, USA. Unfortunately, our website Bollywood.com is being blocked in India, and other nations, maliciously. We are getting traffic only from bots, and the active "user" number is around 300-400 entities daily. We want to investigate DNS/SNI/TLS level reachability of Bollywood.com from Indian ISPs to diagnose suspected censorship, or malicious filtering by Indian telcom companies. Can we get credits to run these probes on your websites? I would appreciate any help from members. Thanks, Best Regards, Kip

4 4

DNS measurement for newer record types - HTTPS & SVCB & more
by Petr Špaček 06 May '26

06 May '26

Hello! Would it be possible to add newer record types to allowed set of "query_type" parameter values for DNS measurements? Specifically I would like to use "HTTPS" and "SVCB" record types, RFC 9460, published in November 2023. On a more generic note: The filter already allows four RR types with weird corner cases - namely NS, DS, ANY, RRSIG. Based on that I think if anything wanted to explode because of RIPE Atlas DNS queries it already did. If you are open to adding more types, I think adding all standardized values from https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-pa… would be very safe and would expand utility for deployment testing of existing protocols. Even better would be to just take integer value. That's what all DNS software does - see RFC 3597 - published in 2003. With integer value we could even use RIPE Atlas for IETF work in the DNS WGs. Thank you for considering the three options above. -- Petr Špaček Internet Systems Consortium

1 0

[Probes used in measurement]
by SIPASSEUTH Adrien 05 May '26

05 May '26

Hello, I want to supervise health from my measurement with https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/status-checks/ But there are all probes result even probes in "NOT parcipating" status. It is possible to removed probes in stats "NOT particpating" from a measurement ? [cid:dc3f3b43-9c0c-4082-a473-f74b19398a2d] I can't find a endpoint which remove this probes from my measruement. Regards, Adrien

2 1

Atlas UI updates for 2026-04-29
by Stephen Suess 29 Apr '26

29 Apr '26

Hello Atlas fans, We have just updated the UI with a new fullscreen view for the Region Meshes use case, as well as some under the hood changes related to the system used to log in to Atlas. In addition, we are deprecating TraceMon (in favour of Khipu) and will be removing it from Atlas after the upcoming RIPE meeting. If there is functionality that you use in TraceMon that is not available to you elsewhere within Atlas, please let us know and we will evaluate. Kind regards, Stephen Atlas UI

1 0