Connect whoever you already use

Reads

• Zones you can access, their status, and their nameservers
• DNS records and DNS query analytics where your plan exposes them
• HTTP request and visit counts, filtered to eyeball requests
• Security events, with the action and rule breakdown the provider supplies
• Bot classification, only where the connected plan exposes the fields
• Email Routing configuration, rules, and aggregate activity, when you already use it

Never changes

• DNS records, nameservers, and zone settings
• Firewall, WAF, and bot rules
• Email Routing configuration, rules, or destinations
• Anything about your account or its plan

You need

• A Cloudflare account with the zones you want to watch
• Authorization through Cloudflare OAuth, using read scopes only

Typical freshness

Hourly to daily, depending on your DomainOverseer plan and the dataset.

Known limits

• HTTP, firewall, and bot data require traffic to pass through proxied records. A DNS-only record still provides authoritative DNS data, but no HTTP or WAF traffic data.
• Bot scoring and some security analytics are gated by the Cloudflare plan on the account. Where the fields are absent we show unavailable rather than zero.
• Security event retention on lower plans can be about a day, so history from before you connected cannot be recovered.
• Adaptive datasets can be sampled, and we keep that sampled state visible on the values it applies to.

Reads

• Teams, projects, and the domains attached to each project
• Recent deployments with state, commit, branch, and duration
• Web Analytics visitors, page views, and allowlisted custom events

Never changes

• Deployments, rollbacks, and promotions
• Environment variables and project settings
• Domains attached to a project

You need

• A Vercel account with the projects you want to watch
• Web Analytics enabled and instrumented on each site you want traffic for

Typical freshness

One to six hours, depending on your plan and the provider reporting delay.

Known limits

• Web Analytics has no history from before it was installed on a site.
• The public analytics API does not reproduce every hostname filter shown in the Vercel dashboard. Where several domains share one project, we do not allocate project-level analytics between them by guessing.
• Vercel visitor identity does not carry across applications, so summing visitors across domains counts the same person more than once. We label the total accordingly.

Reads

• The Analytics accounts and properties your Google account can access
• Active users, sessions, new users, engaged sessions, page views, and event counts

Never changes

• Property configuration, data streams, and any report or audience

You need

• A Google Analytics property and web stream for the site
• The Google tag installed on the site

Typical freshness

Every six to twenty four hours. Values can change for a day or two after collection.

Known limits

• Users are not deduplicated across properties, so a portfolio total counts the same person more than once.
• Approximation, thresholding, and sampling apply, and we preserve that metadata rather than presenting a clean number.
• Vercel Web Analytics does not populate Google Analytics. Each site needs its own tag.

Reads

• The properties your Google account can access
• Search performance totals and detailed query, page, country, device, and appearance rows

Never changes

• Property settings, verification, or ownership
• Sitemaps and indexing requests

You need

• A verified Search Console property for each domain
• A Google account with access to those properties

Typical freshness

Daily, with recent days replaced as Google finalizes them.

Known limits

• Clicks are not sessions and impressions are not page views.
• Detailed rows are top rows and can be privacy filtered or truncated, so they may not sum to the totals.
• Dates follow Pacific Time, which is how Search Console reports them.
• A Domain property and a URL-prefix property for the same site would double count, so exactly one primary property is mapped per domain.

Reads

• The names, total counts, and unread counts of labels in the authorized mailbox

Never changes

• Labels, filters, and mailbox settings
• Messages, in any way at all

You need

• One Gmail filter and label per domain, created by you
• Authorization of the separate Gmail connection

Typical freshness

One to six hours, depending on your plan.

Known limits

• The consent screen describes this scope as permission to see and edit labels, because Google offers no read-only variant. We call only the list and get methods, and the adapter is tested against an outbound method allowlist.
• It shows counts only. It cannot show a sender, a recipient, a subject, a snippet, or a message.
• It covers only the mailbox that completed authorization. Search Console ownership, DNS verification, and a Workspace domain grant no mailbox access.
• Unread counts are never added across domains, because forwarded mail and overlapping filters can put one message in several labels.

Reads

• Public DNS records through a DNS-over-HTTPS resolver
• An HTTPS request to the monitored host, following redirects under a strict policy
• The certificate presented on that connection
• Registration data from the registry, where it publishes an RDAP service

Never changes

• Nothing. These are read-only observations of public information.

You need

• Only that you add the domain

Typical freshness

Availability follows your plan cadence. DNS, certificates, and mail records are checked less often, because they change rarely.

Known limits

• Availability is a single-service check from one place. It is not a multi-region service level measurement and we do not present it as one.
• RDAP coverage varies by registry. An absent expiry date means the registry did not publish one, not that the domain has no expiry.
• DKIM is only checked for selectors you supply, because a selector that does not resolve proves nothing about whether DKIM is configured.