Methodology

The methodology distinguishes exact processing totals from statistically estimated distinct counts, with the scope, precision and limitations of each measure stated below.

Collection

Private collectors download and verify entries from monitored public Certificate Transparency logs. They process the whole feed but retain detailed certificate metadata and a leaf certificate only when a name matches a subscription watchlist.

Raw entries and duplication

“CT log entries today” and “this month” are exact processing counters. They reset at the start of each UTC day and calendar month. They are not unique-certificate totals: the same certificate or precertificate can be submitted to multiple logs and therefore appear more than once. The cumulative processing total remains available through the public statistics API.

Approximate distinct counts

Unique certificates, DNS names, registrable domains and pair counts use compact probabilistic sketches. With the current precision, the expected relative standard error is approximately 0.20%. Estimates may move by more or less than the true change over short intervals.

CT log coverage

The configured-log total comes from the current monitored log lists used by the collectors. A configured log is counted as healthy when its locally verified state records a successful update within the preceding two hours. The active-log figure identifies configured logs whose published issuance period includes the current time. Future and recently retired shards remain configured so continuity is preserved.

Domain interpretation

A DNS name is a certificate name such as www.example.com. A registrable domain is the effective base domain such as example.com, determined using public suffix rules. Wildcards are normalised for counting.

Most active domains

The domain-activity ranking uses a separate bounded sample of up to 262,144 distinct certificate–registrable-domain pairs covering today and the previous 29 UTC dates, independent of customer watchlists. Identical certificate TBS fingerprints appearing in several logs count once per domain across that rolling window; a certificate covering multiple domains can count for each. For this ranking, ICANN public suffix rules consolidate all subdomains under their base domain, including hosted service namespaces such as snowflake.app. Each certificate counts once per base domain even if it covers several child namespaces. The other global domain sketches retain their existing full-PSL interpretation, including private suffixes.

Before the sample fills, observed counts are exact. After that, counts and rank order are estimates obtained by scaling sampled counts by the sampling probability. Per-domain approximate relative standard error is shown with the counts; it is not the 0.20% error of the global sketches. Domains with fewer than 10 sampled pairs are omitted once sampling begins, and close rankings are uncertain. Only the top-100 summary is published; the bounded hashed pair sample is retained locally by the collection service.

A new ranking grouping starts a fresh sample rather than adding old child-domain estimates, which could double-count overlapping certificates. While the 30-day window fills, the caption states the actual observation start date; earlier observations are not included. Each UTC date has a bounded sample. Daily hashed identities are merged and deduplicated; old date buckets expire as the window advances, without resets at month boundaries. Only today and merged previous days are held in memory; up to 30 daily snapshots live on disk and are included in encrypted collector backups. These are certificates observed, not website traffic or certificates necessarily issued or deployed in that window. Delayed logs can move older certificates into a later observation window. Older rolling windows cannot be reconstructed from aggregate totals.

Updates and retention

The collectors save aggregate summaries about every five minutes and upload the latest totals alongside freshly sampled coverage and backlog every two minutes. The status page and status API cache responses for up to 30 seconds; an already open page changes only when refreshed. Historical statistics and incident timelines retain roughly 15-minute snapshots rather than every status sample. Public history is retained for up to three years and drives the hourly, daily, monthly and growth charts. A delayed timestamp means the latest upload has not yet arrived; it does not necessarily mean collection has stopped. Private live certificate matches are retained for up to one year; initial historical inventories are bounded separately.