- network-health - lists.torproject.org

tor metrics being scraped to make ip banlists
by SkirtWise0Cornflake 18 Oct '26

18 Oct '26

hi tor metrics team, i am writing about the use of the relay information published on metrics.torproject.org. some online services appear to scrape this data automatically in order to build ip banlist, banning the operators of tor relays from online service sutch as banks, school dashboards etc... i would like to ask whether you would consider placing the relay pages behind a captcha or a similar measure to discourage automated scraping . i understand that the consensus is public by design, but i would welcome any measure, or any alternative approach you may recommend, that could help reduce indiscriminate blocking of tor users. thank you for your time and for your work on tor. Sent with [Proton Mail](https://proton.me/mail/home) secure email.

1 0

Heads-up: 1aeo.com adding 64 middle relays in 64.65.3.0/24
by Tor at 1AEO 16 Oct '26

16 Oct '26

Hi Tor Network Health team, We (1aeo.com) have deployed 64 additional middle relays (DirCache 0, ExitPolicy reject *:*, Tor 0.4.9.14 on FreeBSD 15.1-RELEASE-p5) in 64.65.3.0/24 (bringing that /24 from 32 to 96 relays across 64.65.3.2–64.65.3.97). All 64 new relays are configured with our standard ContactInfo (url:https://www.1aeo.com proof:uri-familyid-ed25519) and signed with our Happy Family key (FamilyId ri96phwtVtkwug/HYkK4RdIWGbb5la+8x/Y1TkJdhgs). Will see how much closer we can get to saturating our US West 10 Gbe uplink with non guard and non exit relays. We're around 1 Gbe today with ~200 relays. Most likely to exhaust our compute and memory (or maybe power) before bandwidth. New relays (IP, Nickname, RSA Fingerprint): 64.65.3.14 8ballmjg 7E3D557BCFE20069800D04258DE5D76FE8CA6406 64.65.3.16 akon 8AA6F680AE86F2343A9EB24854E41E22D9F93148 64.65.3.17 antbanks F22026DC24FDE34F8FB7F00FBE7EBC4D8F81629A 64.65.3.18 azdoeordie 303DF0C5052B49C897C3AA346E97CD270AA67157 64.65.3.19 babykeem 855B890FDE2BC15B692BBAA07703FA7E314585A6 64.65.3.21 bgcashmoney 637DB72882A3BEBC497FF6812A03F7EDBE8100A4 64.65.3.24 bigsyke 61349488CD4762FBFB0A7812B648856B1400FC2E 64.65.3.26 brotherali 5DEE3A70DC5E7C439C7DAC33322627AE653640A3 64.65.3.27 canibus 9A1328B75AD43B5ED6D42887086432D2923F4A12 64.65.3.28 caponenoreaga 551B91B9B5C9401D1586A75704EDE8E220752F5E 64.65.3.29 cellycel FB5349F030CD019ADF199CDF3864DD88390B3E80 64.65.3.41 chevywoods 3CA77C98ABF6E473E9C58E7FED33CEFA31B56426 64.65.3.42 chubbrock 6C9B67EFC477CD0B0947DB6434CE70074CA91061 64.65.3.43 clsmooth BB91CFF74168C41CF5210C49579A2D406D779FB4 64.65.3.46 companyflow ECAA589998B87612B6B7C6680698B1EF9CCAF604 64.65.3.47 coolio DC506EDD03DA45DFF0B901A953647DBDE8EE8DF5 64.65.3.48 craigmac 2D928E527DAC9741CEAFD009F8052AC4E14A731C 64.65.3.49 crimeapple D902F13337D842696E5EDE4B4ECD498CA9D4F37F 64.65.3.51 crucialconflict DFE4C510C06F5A56530D702FEBC9559680A3BCA7 64.65.3.52 dazdillinger C995704780DE2CF7D0D96ABBE3B3A06897D2C51C 64.65.3.53 deadprez 31924301F34617411BB8099B82E49E27B093F3AE 64.65.3.54 delthefunky AC4C5B66B3D1A7A5F1BCF56F333CAE164DEAD779 64.65.3.56 devinthedude C387FD8E585BD63D00CA139698C2B6D1C323392B 64.65.3.57 digableplanets 9753CF6D499AFC1F238675FBAA8FB4D003E3D9AE 64.65.3.58 dilatedpeoples BF48B8A66D2519F986D4964B666D48801128BDF7 64.65.3.59 djclarkkent 069EEFFF4E1E1B42C9C53C4ABE1D8C1FDE74831C 64.65.3.60 djclue D8DF79820D7FCF645E56C37FF86B7D8E39755FDA 64.65.3.61 djkayslay 31FCCDF945AD9B4CFB7D9016790CE80D35208F7F 64.65.3.62 djkrush BF40E5B56FD480A2BE3E6206B58620979786BCB2 64.65.3.63 djredalert 088E78E418BB163C51718D44CBAC26B7F46DCC43 64.65.3.64 djscratch F00987C974F6C026D4DC06C8A2EFC9D6341C4165 64.65.3.65 djscrew CC3906441EDF3E0F6B22B163271CDBF9A5A7CDFC 64.65.3.66 djshadow 6EE345D312FDC1CA355F36624798E7B235C747A1 64.65.3.67 domkennedy 599391854081C11A9001B180777D94BA748FE6BD 64.65.3.68 dontoliver D2B80E48C52BEB7D0E528980BF238EB772A09B7D 64.65.3.69 doordie C302FE70042EB2E822186F20E34B9A810DE55BC9 64.65.3.70 eastsidaz 676F60FF1B87D078E3F341F698DB7CFB1A68C6E2 64.65.3.71 eyedea 5F9750CE7F4661AFB60D2D2E876D6E8CCE00E9E9 64.65.3.72 fabolous 5A036020C722BFDDFA1DF9C0ADD12D8E45A28A9D 64.65.3.73 fieldmob 9133475A5DA0CB383EC79D8262EEF4D5F87C381A 64.65.3.74 fleshnbone A195998E28F8EDCCD8146A9965C01B9C4FBF35D0 64.65.3.75 funkflex 084091EBA546E81C74053FE5652CABB5F278F0B3 64.65.3.76 glassesmalone 6AAD269A98DCAEE9F192CA883BCACD2B442F5743 64.65.3.77 grandpuba CFC8F1E57473E7183B06FD64EE2E7E4AD26D2BB8 64.65.3.78 gravediggaz C540ABFFCBA3A48F100AA8E20593CCEBC5C404E0 64.65.3.79 heavyd 9DF37C74CC59A018A800E8D47BAE01A2609B9AD2 64.65.3.80 hieroglyphics 7B1B1A0C78184BB1079B0EF7754B86EE07DEDB69 64.65.3.81 illbill 22CDD759CA5DAA0C426B85F42887254EF76D6CC3 64.65.3.82 isaiahrashad 5D0C5D2A8333E681B84AFE7666FB1E69B6D292E2 64.65.3.83 jarule E9F15BD548E1CCB902175C61D3123F12DFAF8E03 64.65.3.84 jayofelony FBE71251793607858B12A092BC163D77A657E5F5 64.65.3.85 jeruthedamaja 031A49B10CB8F1F9E972D970F64191C0C9AF18F9 64.65.3.86 jlive 2A415829C9E8ED1261C16DA2415ECFC1145B6754 64.65.3.87 jodeci 217CF2CA9316DC6CE515AC48469C22A32271D10D 64.65.3.88 juelzsantana A4663DDA384216B14F9C3F5AEBED98C8B3B3E251 64.65.3.89 junglebrothers E778417FF9EFF191380E41C7F0934A8A9E0B5E68 64.65.3.90 jurassic5 9AD89932F399661273F21508CE560F3E385F3A0A 64.65.3.91 juvenile 69D97F89CC86653CFF7CAEF71F094F446B756109 64.65.3.92 kardinaloffishall DBEFE4AD3E4BB54D7209AC64549300BA44652AB0 64.65.3.93 keithmurray C91FF505ED39FD96183727CECAC76448886620A4 64.65.3.94 keyglock 0928494DC7121EEB47A5F2AAF3E63F4A13EADF4D 64.65.3.95 killahpriest 6F6CE8EA56F5C91A625235EB3ADD3704B5802752 64.65.3.96 kingtee 3A7F213009989AE974EFAAE7B9DCA1C96924B65C 64.65.3.97 kokane 14B8D4C10F445F260464BAF736041FFCDB220266

1 0

Broken link
by Yassof Course 14 Oct '26

14 Oct '26

Hi team On the page https://metrics.torproject.org/oxford-anonymous-internet.html , the link for '[Information Geographies website at the Oxford Internet Institute](http://geography.oii.ox.ac.uk/the-anonymous-internet/).' is 'http://geography.oii.ox.ac.uk/the-anonymous-internet/' and the page is not found. Same link for the picture underneath Best Yassof [Screenshot 2026-10-14 at 16.31.03.png]

1 0

The format of snowflake-stats descriptors and collector-rs
by David Fifield 08 Jul '26

08 Jul '26

For the past 3 months, collector-rs has been making snowflake-stats tarballs in an incorrect format. The recently committed fix for this problem implies that the incorrect format was the result of the Snowflake broker changing the format of its metrics. But this is not the case: Snowflake broker metrics have always (since 2019) contained multiple days of metrics. This was by design, and Java Collector was always able to parse that format. Since the recent fix, collector-rs treats snowflake-stats as a special case ("skip_seed_for_archive"), but Java Collector didn't treat snowflake-stats as exceptional—it parsed snowflake-stats in the same way as other types that have multiple days of data in one file, like bridgedb-metrics and bridgestrap-stats, using a method called parseOneOrMoreDescriptors. In summary, the problem was with collector-rs not parsing the metrics files in the same way as Java Collector did, not because of any change in the output of the Snowflake broker. snowflake-stats is not really a special case, but the collector-rs code now treats it as a special case, which makes me wonder if it could be handled in a more uniform way. This is the issue for collector-rs serving an incorrect format for snowflake-stats tarballs: "Snowflake stats format is broken for April" https://gitlab.torproject.org/tpo/network-health/metrics/collector-rs/-/wor… This is the merge request that closes #48 along with many other things: "Rework archive/publish/sync pipeline; add bridge import; vote & dirauth fixes" https://gitlab.torproject.org/tpo/network-health/metrics/collector-rs/-/mer… I understand that the fix has two parts: 1. Changing the collector-rs to ignore all but the last "snowflake-stats-end": https://gitlab.torproject.org/tpo/network-health/metrics/collector-rs/-/mer… 2. Running a one-time fix_snowflake script that rewrites past downloaded files so that they contain only the last "snowflake-stats-end": https://gitlab.torproject.org/juga/collector-fixes/-/commit/7b0aa3170313cb4… I'll quote from fix_snowflake.rs, because I think it reveals the misunderstanding on the collector-rs side: //! `fix-snowflake` - trim bloated snowflake-stats files down to a single //! reporting period, both in `out/recent/snowflakes/` and in the monthly //! `out/archive/snowflakes/snowflake-stats-*.tar.xz` tarballs. //! //! ## Background //! //! The snowflake broker's `/metrics` endpoint is meant to return a single //! `snowflake-stats-end <date> <time> (86400 s)` reporting block per fetch. //! Starting around collector-rs's deployment in 2026, the broker began //! returning the **entire cumulative history** since 2024-09-19 on every //! fetch instead: every previous day's block concatenated, with the new //! day's block appended at the end. Every file collector-rs wrote during //! that window inherited that bloat verbatim - both the daily files in //! `out/recent/snowflakes/` and the entries written into the monthly //! archive tarballs. The format emitted by the broker /metrics endpoint is not "bloat" and it is not "incorrect". Nor did the format change at any point. Here's a Wayback capture that shows it worked like that in 2020: https://web.archive.org/web/20200619131042/https://snowflake-broker.torproj… The format was intentionally designed this way. Here is part of a conversation with Karsten when the metrics feature was originally designed: https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/work_i… To answer your earlier question above: having just the last 24 hours of data might be problematic if the metrics host goes down for, say, a weekend. Ideally, there would be at least a week of statistics available. Or maybe just accumulate new statistics forever, given the tiny amount of statistics per day. This is the way it is intended to work and the way it worked before. collector-rs should not treat the format as anomalous or unexpected. The old metrics/library had a test case with 2 descriptors in it, since 2019: https://gitlab.torproject.org/tpo/network-health/metrics/library/-/blob/2b6… This is how the old metrics/library handled snowflake-stats descriptors: https://gitlab.torproject.org/tpo/network-health/metrics/library/-/blob/2b6… } else if (firstLines.startsWith("@type snowflake-stats 1.") || firstLines.startsWith(Key.SNOWFLAKE_STATS_END.keyword + SP) || firstLines.contains(NL + Key.SNOWFLAKE_STATS_END.keyword + SP)) { return this.parseOneOrMoreDescriptors(rawDescriptorBytes, sourceFile, Key.SNOWFLAKE_STATS_END, SnowflakeStatsImpl.class); } It called parseOneOrMoreDescriptors with "snowflake-stats-end" as a delimiter. Then it iterated over parsed descriptor and handled each one individually: https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/blob/0… DescriptorParser descriptorParser = DescriptorSourceFactory.createDescriptorParser(); SortedSet<LocalDateTime> snowflakeStatsEnds = new TreeSet<>(); this.outputPathName = config.getPath(Key.OutputPath).toString(); for (Descriptor descriptor : descriptorParser.parseDescriptors( downloadedBytes, null, null)) { ... The important thing to note is that Snowflake is not at all a special case; the detectTypeAndParseDescriptors method calls parseOneOrMoreDescriptors for many different descriptor types (with different delimiters): https://gitlab.torproject.org/tpo/network-health/metrics/library/-/blob/2b6…

2 2

Mid-month descriptors from collector-rs?
by David Fifield 05 Jul '26

05 Jul '26

It used to be that the "archive" directory of collector.torproject.org would serve unchanging descriptor tarballs from past months, along with a more or less continuously updated tarball for the current month. But now it seems that there is no tarball for the current month. See here: https://collector.torproject.org/archive/bridge-descriptors/extra-infos/ https://web.archive.org/web/20260504132617/https://collector.torproject.org… The date is currently 2026-05-04, but the latest tarball is extra-infos-2026-04.tar.xz 2026-05-02 03:42 218M Is there a way to get, for example, descriptors from May 3, without waiting until the end of the month? There is the "recent" directory which might work, but it only goes back a few days. At this moment, "recent" covers from 2026-04-30 to 2026-05-04, but if I were to check on 2026-05-20, say, I might not be able to get descriptors from 2026-05-10. https://collector.torproject.org/recent/bridge-descriptors/extra-infos/ https://web.archive.org/web/20260504132701/https://collector.torproject.org… The reason I'm asking: When I make monthly graphs of snowflake bridges, I usually wait a few days into the next month and download the next month's descriptor to include it with the data. The reason is that the tarball for May, for example, contains descriptors that cover the end of April. Without including the beginning of the next month's data, I found, the last 1–2 days of the previous month's data can be incomplete. For example, I just used https://gitlab.torproject.org/dcf/snowflake-graphs to compute statistics using tarballs up to extra-infos-2026-04.tar.xz. This is showing just one bridge (which consists of 12 tor instances). Notice the last few days of April 2026, the "coverage" drops from from 12.0/12.0 to 9.95/12.0: date, fingerprint, transport, users, num_instances,coverage 2026-04-24,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14592.87,12.00,12.00 2026-04-25,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14615.31,12.00,12.00 2026-04-26,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14992.47,12.00,12.00 2026-04-27,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,15056.68,12.00,12.00 2026-04-28,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,15250.09,12.00,12.00 2026-04-29,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,15034.07,12.00,11.92 2026-04-30,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,12877.20,12.00,9.95 If I regenerate the statistics, manually including also the "recent" descriptors, the coverage gets "filled in" (and the users count correspondingly goes up): date, fingerprint, transport, users, num_instances,coverage 2026-04-24,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14592.87,12.00,12.00 2026-04-25,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14615.31,12.00,12.00 2026-04-26,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14992.47,12.00,12.00 2026-04-27,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,15056.68,12.00,12.00 2026-04-28,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,15250.09,12.00,12.00 2026-04-29,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,15099.58,12.00,12.00 2026-04-30,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14834.64,12.00,12.00 2026-05-01,5481936581E23D2D178105D44DB6915AB06BFB7F,snowflake,14781.53,12.00,12.00

2 3

April and May Microdescriptor Consensuses?
by Ellis Fenske 02 Jun '26

02 Jun '26

Hello, I am an academic working on some Tor research and am trying to download the microdescriptor consensuses and microdescriptors for May and April, and it seems on the CollecTor website that these consensuses are missing from the archive (along with many microdescriptors for April). The regular descriptors seem to be there for May, and recent microdescriptors consensuses are available (though the router status entries in them have future-dated timestamps), but I don't see a way to access the microdescriptor information for this time window. I was hoping you could let me know whether to expect this data to be filled in later, whether I'm misunderstanding something about the way the data is stored, or whether it's just missing. Thanks so much! -- -Ellis

2 2

Why are some recent relay extra-infos so much larger than others?
by David Fifield 18 May '26

18 May '26

The sizes of recent relay extra-info files are really non-uniform. Some are ≈2 MB, while a few are around 100 MB. Why is that? https://collector.torproject.org/recent/relay-descriptors/extra-infos/ https://web.archive.org/web/20260504124134/https://collector.torproject.org… The timestamps of the larger files are around 02:15. collector.torproject.org/recent/relay-descriptors/extra-infos$ du -b * | awk '{printf "%s %9d\n", $2, $1}' 2026-04-30-14-11-19-extra-infos 1276042 2026-04-30-15-14-46-extra-infos 1247336 2026-04-30-16-10-53-extra-infos 2855275 2026-04-30-17-15-35-extra-infos 1753035 2026-04-30-18-15-14-extra-infos 2060495 2026-04-30-19-12-44-extra-infos 2660025 2026-04-30-20-14-53-extra-infos 1568362 2026-04-30-21-13-22-extra-infos 1761678 2026-04-30-22-12-10-extra-infos 1413393 2026-04-30-23-12-17-extra-infos 1905710 2026-05-01-00-11-08-extra-infos 1752284 2026-05-01-01-11-37-extra-infos 1534231 2026-05-01-02-15-15-extra-infos 111364852 2026-05-01-02-16-14-extra-infos 1901771 2026-05-01-03-10-54-extra-infos 2386246 2026-05-01-04-13-07-extra-infos 2167008 2026-05-01-05-13-50-extra-infos 1885811 2026-05-01-06-11-28-extra-infos 1963598 2026-05-01-07-14-22-extra-infos 2573871 2026-05-01-08-12-47-extra-infos 1420773 2026-05-01-09-14-42-extra-infos 1172538 2026-05-01-10-11-11-extra-infos 2023018 2026-05-01-11-14-24-extra-infos 2755937 2026-05-01-12-14-47-extra-infos 2134339 2026-05-01-13-10-51-extra-infos 2432106 2026-05-01-14-12-04-extra-infos 1463049 2026-05-01-15-13-41-extra-infos 1408304 2026-05-01-16-11-20-extra-infos 1214815 2026-05-01-17-14-52-extra-infos 1760421 2026-05-01-18-13-18-extra-infos 1674648 2026-05-01-19-14-23-extra-infos 1702962 2026-05-01-20-13-36-extra-infos 1737346 2026-05-01-21-10-54-extra-infos 1926319 2026-05-01-22-12-52-extra-infos 1667868 2026-05-01-23-10-44-extra-infos 1555635 2026-05-02-00-13-03-extra-infos 1999089 2026-05-02-01-11-28-extra-infos 2173352 2026-05-02-02-15-32-extra-infos 100456075 2026-05-02-02-15-58-extra-infos 1528017 2026-05-02-03-16-55-extra-infos 1789647 2026-05-02-04-14-34-extra-infos 2824311 2026-05-02-05-13-56-extra-infos 2511073 2026-05-02-06-15-40-extra-infos 1742844 2026-05-02-07-11-59-extra-infos 2570830 2026-05-02-08-12-55-extra-infos 1371061 2026-05-02-09-14-25-extra-infos 1628251 2026-05-02-10-13-19-extra-infos 1571755 2026-05-02-11-11-02-extra-infos 1821608 2026-05-02-12-12-16-extra-infos 1371271 2026-05-02-13-11-58-extra-infos 1661234 2026-05-02-14-11-01-extra-infos 1574868 2026-05-02-15-11-16-extra-infos 1242763 2026-05-02-16-10-51-extra-infos 1342396 2026-05-02-17-12-29-extra-infos 1888936 2026-05-02-18-13-52-extra-infos 2304888 2026-05-02-19-12-30-extra-infos 2062860 2026-05-02-20-10-59-extra-infos 1352409 2026-05-02-21-14-36-extra-infos 1781758 2026-05-02-22-14-43-extra-infos 2905690 2026-05-02-23-11-41-extra-infos 1102832 2026-05-03-00-14-02-extra-infos 2498869 2026-05-03-01-13-17-extra-infos 2065183 2026-05-03-02-11-55-extra-infos 1270464 2026-05-03-02-15-15-extra-infos 95955891 2026-05-03-03-12-59-extra-infos 1642662 2026-05-03-04-12-22-extra-infos 1666690 2026-05-03-05-14-40-extra-infos 1917854 2026-05-03-06-11-22-extra-infos 1521837 2026-05-03-07-14-49-extra-infos 2303808 2026-05-03-08-12-57-extra-infos 1712003 2026-05-03-09-13-51-extra-infos 1186784 2026-05-03-10-12-13-extra-infos 1366221 2026-05-03-11-15-02-extra-infos 2046367 2026-05-03-12-15-20-extra-infos 1850313 2026-05-03-13-12-08-extra-infos 1817772 2026-05-03-14-11-49-extra-infos 1906482 2026-05-03-15-10-58-extra-infos 1995252 2026-05-03-16-11-14-extra-infos 2764421 2026-05-03-17-14-16-extra-infos 2263420 2026-05-03-18-11-22-extra-infos 1383370 2026-05-03-19-15-02-extra-infos 2885490 2026-05-03-20-13-33-extra-infos 1640791 2026-05-03-21-13-50-extra-infos 1704498 2026-05-03-22-15-00-extra-infos 1998454 2026-05-03-23-12-27-extra-infos 1963243 2026-05-04-00-11-32-extra-infos 1576046 2026-05-04-01-11-25-extra-infos 2282145 2026-05-04-02-15-22-extra-infos 97728439 2026-05-04-02-16-07-extra-infos 1823340 2026-05-04-03-11-09-extra-infos 1136708 2026-05-04-04-13-17-extra-infos 733055 2026-05-04-05-12-45-extra-infos 2051394 2026-05-04-06-12-31-extra-infos 1921639 2026-05-04-07-14-56-extra-infos 540867 2026-05-04-08-14-21-extra-infos 1347267 2026-05-04-09-12-37-extra-infos 757562 2026-05-04-10-17-40-extra-infos 5263330 2026-05-04-11-14-42-extra-infos 1783890 2026-05-04-12-14-28-extra-infos 1537615 2026-05-04-13-13-04-extra-infos 2080428

2 1

Explanation on (negative) spikes in number of relays
by ttlns 19 Apr '26

19 Apr '26

Around 2 weeks ago, I posted the following concerns regarding "negative spikes" for the number of relays measured by metrics.torproject.org [1] in forum.torproject.org [2] (and earlier on r/TOR [3] ) : > Are there any good explanations on why these spikes occurred? > Might those outages imply some centralized infrastructure? If so, how is that not a major concern? So far, I have not received any definite explanations. If those spikes happen to be measurement errors, I imagine that there should be logs somewhere to support this explanation. 3. Does such evidence exist publicly? 4. If not (3), where would that evidence be stored? Sources: [1] http://metrics.torproject.org/networksize.html?start=2022-01-01&end=2026-03… [2] https://forum.torproject.org/t/explanation-on-negative-spikes-in-number-of-… [3] https://www.reddit.com/r/TOR/comments/1s8wx24/explanation_on_spikes_in_numb… I appreciate any clues, hints, or pointers on where to ask further. Best, ttlns

2 5

Less that two weeks old?
by Johannes Kingma 18 Apr '26

18 Apr '26

https://metrics.torproject.org/rs.html#details/DB16235B1337EEE3D0004F83EF29… I read "This relay appears to be less than 2 weeks old.This blog post <https://blog.torproject.org/lifecycle-new-relay>explains the lifecycle of a new relay, and why it will not be immediately fully used to capacity." But in fact it show history back to about 1.5 years. Has been rebooted less that 2 week ago would be better.

1 0

incorrect data on metrics.torproject.org relay search
by txt.file 14 Apr '26

14 Apr '26

Please explain how a Tor relay can have graphs on https://metrics.torproject.org/rs.html#details/506C582367B6ABED6EEF3936DCEB… since 2023-02-17 but at the same time have "First Seen 2026-04-06 23:00:00 (7 days 9 hours 22 minutes and 50 seconds)" in the data. Why has the "first seen" of my 3 year old relay reset? regards txt.file PS: Am not subscribed to this list.

2 1