How to Configure Advanced Monitor Settings

Use the Advanced Settings to fine-tune exactly how Pulsetic checks your websites, APIs, and servers. The updated interface gives you granular control over everything from network protocols and authentication to custom alert delays and response validation.

Advanced settings ensure your monitoring perfectly matches your exact infrastructure. By customizing these rules, you can accurately test complex API endpoints and eliminate false alarms caused by minor network blips.

Steps to Configure Advanced Settings

Step 1: Access Advanced Settings

You can access these settings for both new and existing monitors:

• For a new monitor: Click Add Monitor on your dashboard, and ensure your Monitor Type is set to Website or Keyword. The settings will appear directly in the configuration pop-up.

• For an existing monitor: Navigate to your Monitors page, click the three dots next to the monitor you want to update, and select Advanced Settings.

Step 2: Configure the Basics

This section defines the core identity of your monitor across your dashboard and alerts.

• URL: The exact web address to be monitored. It must start with http://    or https://   .
• Name: An optional alias to help you easily identify the website later (e.g., "Production API").
• Notes: An optional field to add internal context or instructions for your team regarding this monitor.

Step 3: Configure Notifications

Control exactly when and how often your team is alerted during an outage.

• Notification Delay: Set the number of minutes Pulsetic should wait after detecting an offline status before triggering an alert. This is useful for preventing alerts during minor, split-second network blips.
• Resend Notification Frequency: Configure up to 3 follow-up alerts to automatically trigger at selected intervals if the monitor remains offline. (Note: This does not apply to recovery/back-online notifications).

Step 4: Configure Checks

Define how often the check runs, the protocol it uses, and how long it waits for a response.

• Max timeout in seconds: How long Pulsetic waits for the URL to respond before marking the check as a "timeout" failure.
• Check frequency: How often the monitor runs (e.g., every 1 minute, 5 minutes).
• IP Version: Choose the specific IP protocol used to connect to your website. Select IPv6 if you need to strictly verify reachability over an IPv6 network.
• Enable SSL check: Leave this enabled to receive alerts if your SSL certificate is invalid or expiring (checked every 24 hours).
• Enable Redirect Check: Turn this on to automatically follow HTTP redirects. Disable it if you want to capture and evaluate the original redirect response itself.
• Enable Cachebuster: Appends a random timestamp to your URL on every single check. This forces your server to bypass caching mechanisms (like CDNs) and return a fresh response.

Step 5: Configure Request Settings

Customize the exact payload sent to your server.

• Request type: Choose between HTTP, TCP, or ICMP (Ping).

  HTTP Method: Select the standard method for your check:

  • GET: Retrieve data (Standard website check).
  • POST: Submit data to a resource.
  • PUT: Replace target data.
  • PATCH: Apply partial modifications.
  • DELETE: Delete specified data.
  • HEAD: Retrieve headers without the response body.
  • OPTIONS: Describe communication options.
• Auth. type: Select Basic or Digest authentication to monitor password-protected pages (Requires Username/Password). Leave as None for public pages.
• Body: Input the specific data payload you need to send for POST, PUT, or PATCH requests.
• Request Headers: Click Add new header to pass custom data (like specific User-Agents or API tokens) to your server.

Step 6: Configure Response Settings

Pass or fail your checks based on the specific content and status codes returned by your server.

• Response text / Keyword: Enter a specific string of text. The monitor will fail if this text is missing from the page.
• Case insensitive: Check this box to ignore capitalization when searching for your keyword.
• Response Headers: Click Add new header to verify that specific headers (like Set-Cookie   ) are returned by your server.
• Expected statuses: Define exactly which HTTP status codes mean "Success" (e.g., 200, 201   ). Important: If left empty, Pulsetic defaults to [200-206]. If you enter custom codes here, it completely overrides and replaces the default list.
• Not in response: Enter a specific keyword that must not appear on the page (e.g., "Database Error"). The check will fail if this text is found.

Step 7: Request Preview & Testing

Before saving, ensure your monitor is configured perfectly.

• Request Preview: Review the summary panel at the bottom of the screen. It displays exactly how your compiled request will look, including the remote IP address, timeout rules, and configured headers.
• Run Check & See Result: Click this button to manually fire the check right now. Review the results to ensure your authentication, headers, and keyword rules are working as intended.

Once you are satisfied with the configuration, click Update to save your advanced settings.

How Notification Delay in Minutes Works

To reduce noise from short interruptions, offline alerts are sent only after a delay.

When a monitor changes from online to offline, a 5-minute timer starts. If the monitor stays offline for the full 5 minutes, with no status change during that time, an offline notification is sent when the timer expires.

If the monitor comes back online before the 5 minutes are over, the pending offline notification is canceled and nothing is sent.

If the monitor goes offline again later, a new 5-minute timer starts from that new offline event.

An online notification is sent only if an offline notification was already sent before. This avoids sending a recovery message for an outage that never generated an alert.

Repeated checks with the same status do not create new events and do not restart the timer. Only a real status change, such as online -> offline or offline -> online, affects notification logic.

Example 1: Monitor stays offline

• Monitor goes offline at 12:00
• A 5-minute delay starts
• At 12:05, the monitor is still offline and the status has not changed
• An offline notification is sent

Example 2: Monitor recovers before the delay ends, then goes offline again

• Monitor goes offline at 12:00
• A 5-minute delay starts
• Monitor comes back online at 12:01
• No notification is sent, because the offline delay had not completed yet
• Monitor goes offline again at 12:03
• A new 5-minute delay starts from 12:03
• The offline event from 12:00 is discarded because the monitor did not remain offline continuously for 5 minutes
• At 12:08, if the monitor is still offline and the status has not changed again, an offline notification is sent

Example 3: Offline alert is sent, then the monitor recovers

• Monitor goes offline at 12:00
• A 5-minute delay starts
• At 12:05, the monitor is still offline and the status has not changed
• An offline notification is sent
• Monitor comes back online at 12:06
• An online notification is sent, because the offline alert had already been sent

Important behavior to know

A monitor can only generate one offline alert for the same outage. After an offline notification has been sent, no additional offline notifications are sent unless the monitor first comes back online and then goes offline again.

This means the notification flow is:

online -> offline -> wait 5 minutes -> send offline alert -> online -> send recovery alert