# Monitoring IPs and User Agents



VitalSentinel sends requests to your site from the IP addresses on this page. These addresses are used by:

* [Uptime Monitoring](/features/uptime-monitoring)
* Custom Pod [Synthetic Monitoring](/features/synthetic-monitoring) tests
* The VitalSentinel crawler, which [Site Health Monitoring](/site-health/introduction), [Page Monitoring](/page-monitoring/introduction), [Sitemap Monitoring](/features/sitemap-monitoring), [Robots.txt Monitoring](/features/robots-txt-monitoring) and [domain verification](/getting-started/verifying-domain) use

If your site is behind a firewall or uses IP-based access controls, allowlist these addresses.

<Callout type="info">
  Synthetic tests that run from the default **Google's Servers** location use Google's PageSpeed Insights infrastructure, not these IPs. The addresses below cover uptime checks, Custom Pod synthetic tests and the VitalSentinel crawler.
</Callout>

## Current IP Addresses [#current-ip-addresses]

```
194.163.166.126
157.173.116.60
```

**Last updated:** October 6, 2026

VitalSentinel also publishes the crawler IP addresses, the user agent, the crawl rate and the allowlist steps as JSON. Use this list to keep your allowlist up to date:

```
GET https://api.vitalsentinel.com/api/public/v1/crawler
```

## Uptime Bot User Agent [#uptime-bot-user-agent]

Uptime checks are sent with the following User-Agent string, which you can also match in firewall or WAF rules:

```
VitalSentinel Uptime Bot/1.2 (+https://www.vitalsentinel.com/bot)
```

## Crawler User Agent [#crawler-user-agent]

The VitalSentinel crawler sends this User-Agent string:

```
VitalSentinel Bot/1.2 (+https://www.vitalsentinel.com/bot)
```

* **robots.txt token:** `VitalSentinel-Bot`. Use this name in a `User-agent:` line of your robots.txt.
* **Firewall match:** match on `VitalSentinel Bot`, without the version number. Then your rule continues to work when the version changes.

The crawler also signs its requests with Web Bot Auth (key directory: `https://www.vitalsentinel.com/.well-known/http-message-signatures-directory`).

### robots.txt and Crawl-delay [#robotstxt-and-crawl-delay]

The crawler for Site Health Monitoring and Page Monitoring obeys your robots.txt. It uses the `VitalSentinel-Bot` group, or the `*` group if there is no `VitalSentinel-Bot` group. It also obeys `Crawl-delay` as the minimum time between two pages.

Robots.txt Monitoring and Sitemap Monitoring send the same User-Agent. These fetches read your robots.txt and sitemap files directly, so robots.txt rules do not apply to them.

### Crawl Rate [#crawl-rate]

* Site Health Monitoring loads about one page a minute per site. On the Free plan, it loads one page every 5 minutes.
* On paid plans, Site Health Monitoring can do short extra checks after changes on your site.
* Page Monitoring adds the pages that you watch. This load can be up to 60 page loads a minute per site, but it is usually much lower.
* Each page load also fetches the scripts, styles and API calls of the page.

<Callout type="warn">
  Do not rate-limit these IP addresses below 60 page loads a minute per site. Each page load sends more than one request, so the safest choice is to exempt the addresses from rate limits.
</Callout>

## When to Allowlist [#when-to-allowlist]

You may need to allowlist these IPs if:

* Your site is behind a firewall that blocks unknown traffic
* You use a web application firewall (WAF) with strict rules
* You use bot protection that blocks crawlers
* Your hosting provider restricts access by IP
* You have rate limiting that might block monitoring requests

## How to Allowlist [#how-to-allowlist]

Allow both IP addresses. A User-Agent alone is easy to fake, so do not use it as your only rule. If your tool supports it, also allow requests whose User-Agent contains `VitalSentinel Bot`.

The process varies depending on your infrastructure:

### Cloudflare [#cloudflare]

1. Go to **Security** → **WAF** → **Tools**.
2. Add an IP Access Rule for each IP, with the action **Allow**.
3. If Bot Fight Mode or a rate-limiting rule still blocks the crawler, go to **Security** → **WAF** and add a custom rule.
4. In the custom rule, match requests where the User Agent contains `VitalSentinel Bot` and the IP source address is in the list above.
5. Set the action to **Skip**. Select every security feature that the rule can skip.
6. Move the rule to the top of the list.

Bot Fight Mode and Super Bot Fight Mode need their own exception.

### AWS WAF [#aws-waf]

1. Create an IP set with both IP addresses.
2. In your web ACL, add a rule that matches the IP set, with the action **Allow**.
3. Put the rule before all rate-based rules and managed bot control rule groups.

### AWS Security Groups [#aws-security-groups]

1. Go to **EC2** → **Security Groups**
2. Edit inbound rules
3. Add HTTP/HTTPS rules for each IP

### Akamai [#akamai]

1. Add both IP addresses to a Network List.
2. In Bot Manager, exempt the Network List.
3. In your rate control policy, exempt the Network List.

### Imperva [#imperva]

1. In **Security** → **Rules**, add each IP address as an exception in the WAF and in bot protection.
2. Exempt both IP addresses from your rate-limiting rules.

### Sucuri [#sucuri]

1. Go to **Firewall** → **Access Control** → **Whitelist IP Addresses**.
2. Add each IP address.

### Wordfence [#wordfence]

1. Go to **Wordfence** → **Firewall**.
2. Add each IP address under **Allowlisted IPs**.
3. Optional: add the user agent `VitalSentinel Bot` to the allowlisted services.

### Nginx [#nginx]

Add to your server configuration:

```nginx
allow 194.163.166.126;
allow 157.173.116.60;
```

### Apache [#apache]

Add to your `.htaccess` or virtual host configuration:

```apache
Require ip 194.163.166.126
Require ip 157.173.116.60
```

## Verification [#verification]

After allowlisting, verify VitalSentinel can reach your site:

1. Go to your domain's **Uptime Monitoring** section
2. Check that uptime checks are succeeding
3. Run a **Synthetic Monitoring** test and verify it completes
4. In Site Health Monitoring, open **Settings** and find the **Crawler access** card. This card shows if the crawler can reach your site now.
5. If still failing, verify the IPs are correctly allowlisted

<Callout type="info">
  These IPs may change in the future. We'll notify you via email before any changes to give you time to update your allowlists.
</Callout>

## Related [#related]

<Cards>
  <Card title="Uptime Monitoring" href="/features/uptime-monitoring">
    Availability checks and SSL monitoring
  </Card>

  <Card title="Synthetic Monitoring" href="/features/synthetic-monitoring">
    Lighthouse performance tests
  </Card>

  <Card title="Site Health Monitoring settings" href="/site-health/settings#crawler-access">
    Crawler access and allowlist help in the app
  </Card>

  <Card title="Troubleshooting" href="/help/troubleshooting">
    Solutions to common monitoring issues
  </Card>
</Cards>
