Resource

PulseStack™ Monitoring Locations

Where Our Checks Come From

PulseStack™ checks website, keyword, API, ping and port monitors from three locations: London, New York and Sydney. A monitor is only marked down when at least two of the three locations report a failure, so a network problem at one location does not trigger a false alarm.

Some hosting providers, firewalls and bot filters block automated requests. If they block our checks, you can see false downtime, so it is worth making sure your security settings let our checks through.

Our Check Server IP Addresses

We do not currently publish a list of the IP addresses our checks come from. Rather than relying on an IP allow list, the most dependable way to let our checks through a web application firewall is a custom request header, described below.

30s
Fastest check interval
24/7
Always-on monitoring
3
Check locations
8
Native alert channels

How Checks Are Confirmed

PulseStack™ confirms a failure before it alerts you. Website, keyword, API, ping and port monitors are only marked down when at least two of the three locations agree, and other monitors are re-tested a few seconds later. You cannot choose locations per monitor or change the two-location rule, but together they keep false alarms down while still catching real outages quickly.

The Three Check Locations

London, United Kingdom

Our European check location.

New York, United States

Our North American check location.

Sydney, Australia

Our Asia-Pacific check location.

Response times are recorded and charted for each location, so you can see how quickly your site responds to visitors in each region.

Ready to put this into practice?

Start monitoring your infrastructure today.

Get started

Allowing Checks With a Custom Header

On paid plans, HTTP and API monitors can send custom request headers. Choose a header name and a long random value, add the header to your monitors, then create a rule in your firewall or web application firewall that allows requests carrying it. Keep the value private, because anyone who knows it could use the same rule.

Firewall and WAF Examples

Most web application firewalls can allow traffic based on a request header. The exact steps depend on your provider:

  • Cloudflare: create a WAF custom rule that matches your header and value, and set it to skip the security features that block our checks.
  • AWS WAF: add a rule with a header match statement and an Allow action, placed before your blocking rules.
  • Nginx or Apache: check for the header in your configuration and exclude matching requests from rate limiting or bot blocking.

Network firewalls such as iptables, UFW or Windows Defender Firewall filter by IP address and port rather than by header. If one of those is blocking our checks, contact us at hello@pulsestack.co.uk.

Ready to start monitoring?

Start monitoring in minutes. Free plan included, no credit card needed.

Get started free