Why can't Pingara reach my address?

When you add a monitor with Guided setup or Ara, Pingara first tests your address once, right now, and tells you what happened. This page explains every result and what to do about it.

Try this first: open your address in a browser on a different network, such as your phone with Wi-Fi off. If it loads there, the address is public, and the sections below will narrow down the cause.

How the test works

A test check is a single, one-off request. It runs from Pingara's monitoring locations over the public internet, the same way a monitor's real checks do, so it sees what a customer sees. It usually answers in 5 to 15 seconds.

• Free plans test from one location. A result from one location tells you that location could not reach you, not that nobody can.
• Pro plans test from every monitoring region and show a result for each, so you can see whether a problem is local to one part of the world.
• A test check never counts toward uptime, incidents, alerts or reports, and it does not change any monitor.
• Pingara keeps the address and the result for 15 minutes so the page can show them, then deletes them.
• The test waits up to 10 seconds for a reply and follows up to 4 redirects. It does not send custom headers, a request body or any login details.

A failed test never stops you from creating the monitor. The target might be perfectly fine and only slow right now, and the first real check runs as soon as the monitor is on.

Results at a glance

INVALID_INPUT: that address doesn't look right

Pingara could not read what you typed as a website address or a server name. Common causes are a stray space, a missing dot, or text that is not an address at all.

Fix: type the address the way you would in a browser, for example mybakery.co.uk or https://mybakery.co.uk. For a server ping, use a host name or IP address with no path after it.

PRIVATE_ADDRESS: this address is private

Pingara checks your site from the internet. Addresses such as 192.168.1.10, 10.0.0.5, localhost or a name ending in .local or .internal only work inside a private network, so nothing outside it can reach them, including Pingara. A public name that points to a private address is blocked as well.

Fix: use the public address your customers visit. If the service has no public address, it cannot be monitored from outside, and an internal tool is the better fit. See the Creating Your First Monitor troubleshooting section for the full list of blocked ranges.

DNS_NOT_FOUND: we couldn't find that name

DNS is the internet's address book, and it has no entry for this name. The usual causes are a typo, a domain that has expired or was never registered, or DNS records that were deleted or have not finished propagating after a change.

Fix:

1. Check the spelling, including the ending (.co.uk or .com).
2. Confirm the domain is registered and has not expired at your registrar.
3. Check that your DNS provider has a record for the name. New records can take up to a few hours to spread.

ICMP_BLOCKED: this server ignores pings

The server answered on its web port (443 or 80), but did not reply to a ping. Many servers and firewalls block ping on purpose. A ping monitor on such a server would report it as down all the time, even though it is working.

Pingara only gives this advice when the ping failed in every region tested, a web port answered in at least one, and the ping really was a ping, not a fallback to a plain connection test.

Fix: monitor the website over HTTPS instead. It is what your visitors use, so it is the better check anyway. In Guided setup, press Monitor the website over HTTPS instead. If you must use ping, allow ICMP echo requests from the public internet on your firewall. See Ping Monitoring.

TIMEOUT: it took too long to answer

Pingara waited 10 seconds and got nothing back. The site may be overloaded, very slow, switched off, or behind a firewall that drops traffic quietly instead of refusing it.

Fix:

1. Open the address in your browser. If it loads quickly, try the check again, because it may have been a brief slowdown.
2. If it is slow or fails for you too, look at your server or hosting provider's status page.
3. If you use a firewall or a service that limits visitors by country or IP address, make sure it does not block data center addresses.

You can still switch the monitor on. If the site stays slow, Pingara will show it as degraded or down and alert you.

TLS_ERROR: there's a problem with the security certificate

Pingara could not verify the site's HTTPS certificate. The certificate may have expired, may have been issued for a different name (for example www.example.com when you typed example.com), may be self-signed, or may be missing the intermediate certificates browsers need.

Fix: ask whoever runs the site to renew or fix the certificate. If you manage it yourself, check the expiry date and that the certificate covers the exact name you are monitoring. Free certificates from Let's Encrypt renew automatically when set up correctly.

You can still switch the monitor on. It reports the problem until the certificate is fixed, which is useful in itself. See SSL Monitoring Configuration.

AUTH_REQUIRED: this page needs a login

The address answered, but asked for a username and password first (status 401, 403 or 407). That usually means the server is up and doing its job. A monitor cannot sign in, so a page that always asks for a login would look like a failure.

Fix: monitor a public page instead, such as your home page or a health check address. If the login page itself is what you want to watch, tick Count a login page as up in Guided setup. The monitor then treats 401 and 403 as healthy, along with the normal success codes.

HTTP_ERROR: the site answered with an error

The server replied, but with an error page instead of the page itself. That covers a "not found" page (404), a server error (500 and similar), and a redirect loop (more than 4 redirects in a row).

Fix: check the address points at a page that exists, for example by opening it in your browser. If the site is having trouble right now, you can still switch the monitor on, and Pingara will alert you while the errors continue. If your page legitimately returns a code other than the usual success codes, set the expected status codes in the full form.

CONNECTION_FAILED: the server refused the connection

Pingara found the server, but the connection was refused, reset or dropped. Typical causes are a server that is switched off, a web server that is not running or not listening on that port, or a firewall that blocks visitors.

Fix: check the server and the web service are running, and that the address and port are right. Then check that no firewall rule is rejecting connections from the public internet.

NO_RESPONSE: no response

Our check did not come back in time, usually because the monitoring location was busy or briefly unable to report. It is usually on our side, not yours. The line can change to a real result if the answer arrives late.

Fix: try the check again in a moment. If it keeps happening, you can switch the monitor on anyway: the first real check runs straight away. If it persists for hours, email support@pingara.io.

If the test passes but the monitor still fails later

A test check is one request at one moment. A monitor keeps checking, and sites can be fine now and fail later. For real checks, Pingara opens an incident only after consecutive failures, and Pro plans with several regions require a quorum of regions to agree before alerting. On Free plans, a monitor runs from one location. See Understanding Incidents and Monitor Intervals and Regions.

Next steps

• Guided setup and Ara, Pingara's assistant - The guided form and the AI assistant
• Creating Your First Monitor - Every field in the full form
• Ping Monitoring - When ping is the right check