A LITTLE OWL KNOW-HOW
FAQ & help
Answers about PingHoot, plus a helping wing when a check cannot get through.
Using PingHoot
What counts as a monitor?
One specific URL. Uptime, text rules and SSL checks for that URL are included together. A homepage and a separate checkout page use two monitors.
Can I use the free plan for a business?
Absolutely. Your 5 free monitors can watch personal projects, business websites or client sites.
How quickly will I hear about an outage?
Free plans check every 5 minutes; paid plans every 1 minute. By default, two consecutive failures confirm an outage. Choose one to five failed checks per monitor, with confirmation retries about one minute apart. Queue and alert delivery can add time.
How do SMS alerts work?
Paid plans include a monthly allowance of SMS credits. Every plan, including Free, can buy extra credits. Verify your mobile number, then enable SMS for each monitor. One text uses one credit; recovery texts are optional and use another credit.
Does the text check run JavaScript?
It checks the HTML returned by the server. Content added only by JavaScript is not checked. Use Test now during setup to verify your phrase.
Can I send alerts to my own application?
Yes. Paid plans support a custom webhook URL for each monitor, with optional recovery notifications. View the full request and response in your webhook history and replay a delivery when you need to.
When a website cannot be monitored
A website can work in your browser but refuse an automated check. The check records what PingHoot receives, which may differ from what your visitors see.
Could a firewall or security plugin be blocking PingHoot?
Yes. Firewalls, security tools and CMS plugins such as Wordfence can sometimes mistake automated monitoring requests for suspicious traffic and block them, even though your website works normally in a browser.
If this happens, try allowlisting PingHoot's monitoring IP address in your firewall or security plugin. If you're unsure how, your hosting provider should be able to help.
Why does my website only fail some of the time?
Intermittent failures can happen for a number of reasons, including temporary server overload, hosting issues, database problems, caching, rate limiting or firewall rules.
Your website may be working normally by the time you check it, even though it returned an error when PingHoot performed its check.
Why does my browser work while PingHoot reports a failure?
Hosting firewalls, bot protection, country restrictions and rate limits can block monitoring traffic. Your browser may already have a login or a cookie that lets it through. PingHoot does not sign in, solve CAPTCHAs or execute JavaScript challenges.
Check the latest error and HTTP status in your monitor history. A 403 can indicate a denied request, and 429 usually indicates rate limiting. A 503 means the service is temporarily unavailable: the server may be overloaded or undergoing maintenance, but some firewalls or security plugins also return it when blocking automated requests. A timeout can mean a slow server or a blocked connection. These are clues, not proof of a firewall problem. Ask your host or site administrator to check the server and security logs at the failed check time.
If a challenge page returns HTTP 200, an uptime check alone may pass. Add required text that appears in your real page's server-rendered HTML to help detect that response.
Firewall Issues
If your website works in a browser but its first checks fail, your host, CDN or a WordPress / CMS security plugin may be blocking PingHoot. Check the failed request in its logs before changing protection.
PingHoot monitoring IP addresses
139.59.178.246
Use these published monitoring source IPs when asking your host or plugin provider to allow our checks. Revisit this list if you change an exception; the public website's IP may differ from the monitoring servers.
What should I ask my hosting company to allow?
Ask your host to check its firewall and bot-protection logs for the monitored URL at the failed check time, using UTC. Our website checks send this user-agent:
PingHoot (website health monitor)
Favicon lookups use PingHoot (favicon check).
Ask for a narrow exception for monitoring requests to the public hostname and path you own. A user-agent can be copied by anyone, so it is not proof that a request came from PingHoot. Where possible, also restrict the exception to monitoring source IPs confirmed with us; do not assume pinghoot.com's website IP is the checker's IP.
If your host cannot permit automated requests, that URL may not be suitable for external monitoring. A public health endpoint can be an alternative, but it only measures that endpoint and does not prove the whole website works.
Wordfence: my WordPress site works, but PingHoot cannot check it
- In WordPress, open Wordfence → Tools → Live Traffic. Find the failed request using the monitoring IP above, URL and check time. Check whether a firewall rule, country restriction or rate limit blocked it.
- Ask your site administrator to review the blocking rule and allow the legitimate monitoring request. Wordfence's Firewall → All Firewall Options → Advanced Firewall Options includes an IP allowlist. Only add confirmed monitoring source IPs if needed: this setting bypasses all Wordfence rules for those IPs.
- Save the change, run Test now in your PingHoot monitor editor, and check Live Traffic again. Leave Wordfence enabled; an exception in Wordfence will not remove a separate block at your host or CDN.
Other WordPress or CMS firewall plugins
Other security plugins, hosted firewalls and CMS extensions can also block automated traffic. Look in their security, blocked-request or traffic logs for the exact URL, failed check time and PingHoot monitoring IP above.
Ask your administrator or the plugin's support team for a monitoring exception. Give them the source IPs, user-agent and error from PingHoot. Settings differ between plugins: prefer the smallest exception they support for the public page being monitored, and check bot protection, country restrictions and rate limits.
Keep protection enabled. After saving, use Test now and confirm that the request reaches the real page. If the plugin never sees the request, ask your host or CDN to check its firewall too.
Contact PingHoot support if you are unsure what is blocking the check.
How can I let PingHoot through Cloudflare?
- Find the failed request in Cloudflare's Security Events using its time, hostname and path. Identify which product or rule blocked or challenged it.
- For supported products, create a custom rule under Security rules with a Skip action. Match the exact user-agent above, your monitored hostname and path, and the GET method. Add confirmed monitoring source IPs where available.
- Skip only the rule or security feature causing the false positive. Keep logging enabled and place the exception before the rule it needs to bypass. Avoid an exception that skips every protection across your whole website.
- Save it, run Test now in PingHoot's monitor editor, then confirm the request in Cloudflare's logs.
Bot Fight Mode is different: custom Skip rules cannot bypass it. Super Bot Fight Mode supports scoped Skip exceptions. If Bot Fight Mode is responsible, review the available options with your host or Cloudflare before changing site-wide protection.
Cloudflare: configure Skip rules · Cloudflare: bot-protection false positives
DNS, SSL and other check issues
What if it is a DNS, SSL or connection error?
Check the exact URL, public DNS records and certificate chain with your host. PingHoot requires a publicly reachable HTTP or HTTPS URL on port 80 or 443. Private networks, localhost addresses and URLs containing login credentials are not supported.
Fix expired or invalid certificates rather than disabling certificate checks. Redirects must also lead to a permitted public URL; PingHoot rejects HTTPS-to-HTTP downgrades. If the response times out or is too large, ask your host about the response or choose a suitable lightweight public page.
Why is my required text missing even though I can see it?
Text checks read the HTML sent by the server. They cannot see text loaded later by JavaScript or shown only after signing in. Check your phrase, case-sensitivity setting and the server response. A firewall challenge or a redirect to a login page can also explain missing text.
Use a phrase in the initial HTML and try Test now again. Do not remove a useful text check just to make a challenge page look healthy.
