Why verification at source is better than waiting for another server to confirm
12 Mar, 2026
Most Fequently Asked Questions, we are asked. From billing to operational functionality
Sign in to Funny Monitors, select the option to add a monitor, choose the monitor type, and enter the requested target and settings. For a website monitor, this is normally a URL. Ping and port monitors use a hostname or IP address, with a port number also required for port monitoring. After saving the monitor, attach the notification contacts or integrations that should receive alerts.
Funny Monitors supports monitoring types including:
A new monitor normally begins checking shortly after it is created and successfully saved. The exact timing depends on the monitor interval, configuration, queue, and plan. If a monitor continues to show no data after allowing sufficient time for its first check, verify its target and settings or contact support.
Yes. Use an HTTP(S) monitor and configure the appropriate URL, request method, headers, authentication, payload, expected response code, and keyword or response conditions available under your plan.
An ordinary monitor must be able to reach the target from the public internet. For an internal system that cannot accept inbound monitoring requests, add our ip ranges from Funny Monitors to your firewall.
Funny Monitors sends an HTTP or HTTPS request to the configured URL at the selected interval. The response status, connection result, timeout, certificate behavior, and any configured conditions determine whether the monitor is considered up or down.
Ping monitoring sends ICMP echo requests to a hostname or IP address. A response indicates that the network host is reachable by ICMP. Ping does not prove that a website or application running on that host is working, so use an HTTP(S) monitor when you need to check the web service itself.
Port monitoring attempts to connect to a specified hostname or IP address on the configured port. It is useful for checking whether services such as mail, database, DNS, or other network applications are accepting connections. A successful connection confirms that the port responded; it does not necessarily validate every application-level function behind that port.
Depending on the monitor type and plan, HTTP monitors may support methods such as HEAD, GET, POST, PUT, PATCH, DELETE, and OPTIONS. Keyword monitoring normally requires a method that retrieves response content. Use the least disruptive method appropriate for the target. Never configure a monitoring request that creates, changes, or deletes real data unless you control the target and have designed a safe test endpoint.
Yes, where supported by your plan. Custom headers can be used for content negotiation, API authentication, cache control, virtual-host routing, or other endpoint requirements. Treat authorization headers, tokens, and secrets as sensitive. Limit their permissions, rotate them when necessary, and never publish them on a public status page or in support content unnecessarily.
Where available, Funny Monitors supports HTTP authentication settings for protected endpoints. Use credentials created specifically for monitoring with the minimum permissions required.
Yes, where advanced HTTP settings are available. You can configure the response status codes Funny Monitors should treat as successful or unsuccessful. This is useful for endpoints that intentionally return a non-standard success code.
Where the setting is available, an HTTP(S) monitor can be configured to ignore certain SSL errors. Doing so reduces the monitor’s ability to warn you about certificate problems, so it should be used only when you understand the security impact.
Yes. SSL monitoring can alert you before a certificate expires. Keep the relevant notification contacts attached and verify that certificate reminders are enabled for the monitor.
Yes, where cache-bypass or cachebuster functionality is available. A changing query value or suitable request header can help prevent a CDN, proxy, or application cache from returning a previously stored response. Use cache bypass carefully because it may increase traffic and load on the monitored origin.
Yes. An HTTP(S) monitor can request the file URL. For large files, use HEAD where appropriate so the monitor checks availability without downloading the entire file. The remote server or CDN must support the selected method and allow requests from Funny Monitors.
Funny Monitors checks the target from its monitoring infrastructure at the configured interval. When a connection or response fails, it performs verification checks to reduce false alarms. If the verification checks also fail, the monitor is marked down and attached notifications are triggered. An explicit HTTP error status configured as down may cause a monitor to be marked down immediately because the target itself returned a definitive response.
Funny Monitors continues checking the target so it can detect recovery. When the target satisfies the configured success conditions again, the monitor is marked up and recovery notifications are sent according to your notification settings.
Results can differ because of:
Yes. Ping checks whether the host responds to ICMP. The web server, application, database, or a dependency can fail while the underlying host continues replying to ping. Use an HTTP(S) monitor to check the website or application.
Yes. A false positive can result from a temporary network path issue, timeout, firewall rule, rate limit, DNS inconsistency, certificate problem, regional block, or an overly strict monitor condition. Funny Monitors uses verification checks to reduce this risk, but no external monitoring service can eliminate it completely.
It is possible. A short outage may begin and end between checks, affect only a region not used for that check, or return a response that still satisfies the configured conditions. Faster intervals, multiple monitor types, content checks, and suitable alert rules can improve coverage.
Check that:
The most common reason is that no notification contact or integration is attached to the monitor. Also check:br>
Review the response-time history and the failure details. Then check the target from an external network, confirm DNS and firewall rules, review server capacity and logs, and ensure Funny Monitors is not being blocked or rate-limited. Intermittent long response times before a timeout may indicate load, database, upstream, network, or resource-exhaustion problems.
Not always. Allowlisting may be necessary if your firewall, CDN, hosting provider, bot protection, geographic restriction, or security software blocks monitoring traffic. Use the current Funny Monitors monitoring IP list published in the dashboard, documentation, or support resources. Because monitoring infrastructure can change, do not rely on an old copied list indefinitely. The current IPv4 Stack will always route via 46.225.193.64/26 and our current IPv6 Stack will always route via 2a01:4f8:fff0:2b::/64
Funny Monitors identifies HTTP monitoring requests using its published monitoring user-agent. Use the exact current value shown in the Funny Monitors documentation or provided by support when creating firewall, analytics, or bot-management rules. The current user agent is "Mozilla/5.0+(compatible; FunnyMonitors/1.0; https://www.funnymonitors.com/)"
Most browser analytics platforms rely on client-side JavaScript, which ordinary HTTP monitoring requests do not execute. Server-side analytics, access logs, CDN analytics, and trackers that count raw requests may record Funny Monitors checks. Filter the Funny Monitors user-agent or monitoring IP addresses where appropriate, taking care not to block the actual monitor.
Only if the monitor uses a location permitted by your geographic restrictions. Verification checks may originate from additional locations. Adjust the restriction or allowlist Funny Monitors infrastructure if you want all relevant checks to reach the target.
When Cloudflare proxies a website, Funny Monitors normally sees Cloudflare’s response rather than communicating directly with the origin server. If Cloudflare serves a successful cached response, the monitor may consider the site up even when the origin has a problem. If Cloudflare returns an error status configured as down, the monitor reports a failure. To monitor origin availability separately, create an appropriate direct-origin monitor and secure it so only authorized monitoring traffic can reach it.
Bot protection, managed challenges, browser checks, rate limits, geographic rules, IP reputation, and web application firewalls can block automated monitoring requests. Allowlist the Funny Monitors monitoring IPs or user-agent, create a dedicated health endpoint, or adjust the relevant security rule without weakening protection for ordinary traffic.
You can, but deletion permanently removes the monitor and its associated history. Recreating it may also change its monitoring configuration or assigned infrastructure. First record the settings and export any history you need.
Yes. Pausing stops scheduled checks and alerts while retaining the monitor and its existing history, subject to plan retention limits. Resume it when you want checks to continue.
Where maintenance windows are available, schedule planned work in advance and associate the correct monitors. Checks or incident records may continue depending on configuration, but notifications can be suppressed for the maintenance period.
Yes. Combining monitor types can provide better coverage. For example, use:
