The Settings page controls the defaults and support tools Siteimp Watch uses across your local workspace.

Use this page to set app-wide monitoring defaults, manage Slack and Discord notification destinations, choose app-level notification defaults, test destinations, and work with local support logs.

Settings do not replace property or target controls. They provide starting values and reusable tools. Individual properties and targets can still have their own monitoring choices.

What this page is for

The Settings page answers three practical questions:

What should new monitoring items inherit?

Where can Watch send notifications?

What support information can I copy or save if troubleshooting is needed?

This page is local-first. Notification destinations are stored locally. Support logs are stored locally. Logs are not attached to support requests automatically.

What you can do here

Refresh settings

Use Refresh settings to reload monitoring defaults and notification destinations from this computer.

Refresh is useful if you changed settings elsewhere in the app, added a destination from another page, or want to confirm the page is showing the latest local state.

Set monitoring defaults

The Monitoring defaults card controls app-wide defaults for new properties and targets.

These defaults are used when Watch needs a starting value. Existing property and target settings can still override them.

You can set:

  • Retention
  • Default interval
  • Failure threshold
  • Default check mode
  • Enable notifications by default

Retention

Retention controls how long Watch keeps monitoring results before pruning them.

For example, if retention is set to 30 days, Watch can remove monitoring results older than 30 days during pruning.

Retention must be at least 1 day.

Default interval

The default interval is the number of seconds between checks for new targets.

For example:

300 seconds = 5 minutes
60 seconds = 1 minute
5 seconds = fast local testing

Default interval must be at least 1 second.

Short intervals can be useful for local development, but they create more monitoring results. For public websites, use a schedule that is respectful and practical.

Failure threshold

The failure threshold controls how many failed checks are required before a target is considered down.

For example:

1 = mark down after the first failed run
3 = wait for three failed runs before marking down

A higher threshold can reduce noise when a target has occasional network bumps. A lower threshold reports problems sooner.

Failure threshold must be at least 1.

Default check mode

The default check mode decides what kind of checks new targets inherit.

The options are:

  • Ping and fetch
  • Ping only
  • Fetch only

Ping and fetch is the broadest option. It lets Watch try both a lightweight availability check and an HTTP fetch check.

Ping only is useful when you care about basic reachability.

Fetch only is useful when an HTTP response is the important signal.

Enable notifications by default

Use Enable notifications by default to decide whether new targets should be eligible for notifications.

This does not send messages by itself. Watch still needs a destination and notification routing before it can send alerts or recovered messages.

Set notification defaults

The Notification defaults card appears after at least one notification destination exists.

Use this card to choose app-level defaults for:

  • alert messages
  • recovered messages

App defaults are used when a property does not choose its own notification routing.

Enable app-wide monitoring notifications

Use Enable app-wide monitoring notifications to allow Watch to use the notification defaults.

If app-wide monitoring notifications are disabled, Watch can still monitor targets, but app-level notification defaults will not send messages.

Default alert destination

The default alert destination is where Watch can send monitoring alert events when a property does not override the alert route.

An alert usually means a target went down or needs review.

Default recovery destination

The default recovery destination is where Watch can send recovered messages when a property does not override the recovery route.

A recovered message means a target came back after an alert state.

Notification destinations

The Slack and Discord destinations card manages reusable user-owned notification destinations.

A destination is a saved webhook that Watch can use for:

  • test messages
  • monitoring alerts
  • recovered messages

Destinations are not the same as the support path. Your notification webhooks do not control how Watch contacts Siteimp support.

Add a destination

Use Add destination to save a Slack or Discord webhook.

You will choose:

  • a readable label
  • a provider
  • a webhook URL
  • whether the destination is enabled

Use a label that will make sense later.

Good examples:

Operations Slack
Website alerts
Client monitoring Discord
Weekend on-call

Webhook URLs are saved locally and used for user-owned monitoring notifications.

Edit a destination

Use Edit to change a saved destination.

You can update the label, provider, webhook URL, or enabled state.

Editing a destination affects future notifications that use that destination.

Disable a destination

A disabled destination stays saved, but it will not receive monitoring notifications.

This is useful when you want to pause a destination without deleting it.

Test a destination

Use Test to send a test notification.

Testing confirms that Watch can use the saved destination and that the external service accepts the webhook.

If the test fails, check the webhook URL, the provider, and your network connection.

Delete a destination

Use Delete to remove a notification destination.

Deleting a destination also removes property notification links that point to it. Monitoring can still run, but alerts or recovered messages that depended on that destination will no longer be sent there.

Watch asks for confirmation before deleting a destination.

Support logs

The Support logs card gives you access to local diagnostic logs.

Watch keeps these logs on your computer to help troubleshoot local problems. They are not sent automatically.

If Siteimp support asks for logs, you can:

  • refresh the log list
  • copy the latest log
  • save the latest log file
  • open the local log folder
  • copy a specific log
  • save a specific log

Refresh logs

Use Refresh logs to reload the local support log list.

This is useful if you just ran a support diagnostic, restarted the app, or sent a support request and want to see the newest log file.

Copy latest log

Use Copy latest log to copy the newest log contents to your clipboard.

You can paste the copied contents into an email or support message if Siteimp support asks for them.

Save latest log file

Use Save latest log file to download the newest log as an .ndjson file.

Save it somewhere easy to find before attaching it to an email or support message.

Open log folder

Use Open log folder to open the folder that contains local support logs.

This is useful if support asks for more than one log file or if you want to inspect the files yourself.

Copy or save a specific log

Each log row has its own Copy and Save buttons.

Use these when support asks for a specific run log, or when the latest log is not the one you need.

What this page does not do

The Settings page does not send support logs automatically.

The Settings page does not expose the application-owned support webhook.

The Settings page does not make notification destinations global support channels. Slack and Discord destinations are for user-owned monitoring notifications.

The Settings page does not override every property and target. It sets defaults. Property dashboards and target details can still show more specific monitoring state.

Troubleshooting messages

Retention must be at least 1 day

Retention cannot be blank, zero, negative, or a decimal.

Enter a whole number of days, then save monitoring defaults again.

Default interval must be at least 1 second

The default interval cannot be blank, zero, negative, or a decimal.

Enter a whole number of seconds, then save monitoring defaults again.

Failure threshold must be at least 1

The failure threshold cannot be blank, zero, negative, or a decimal.

Enter a whole number of failed checks, then save monitoring defaults again.

Choose a supported check mode

Watch did not recognize the selected check mode.

Choose one of the available options:

  • Ping and fetch
  • Ping only
  • Fetch only

Then save monitoring defaults again.

Watch could not find the saved destination ID for this test

Watch tried to send a test notification, but the destination ID was missing.

Refresh Settings and try again. If the destination still cannot be tested, delete it and add it again.

Watch could not send that request because a required value was missing

Watch tried to send a settings request, but one of the required values was missing.

Refresh Settings and try again. If the problem continues, open the HelpDrawer and contact technical support.

Monitoring defaults could not be loaded

Watch could not load the app-wide monitoring defaults from this computer.

Use Try again or Refresh settings. If the message keeps appearing, open the HelpDrawer and contact technical support.

Notification settings need review

Watch could not load or save notification settings.

Use Try again or Refresh settings. If you were testing a destination, check the webhook URL and provider.

Support logs need review

Watch could not list, copy, save, or open local support logs.

Try the action again. If copying fails, try saving the log file. If saving fails, try opening the log folder.

Privacy notes

Settings are local to this Siteimp Watch installation.

Notification destinations are user-owned webhooks saved locally.

Support logs are local diagnostic files. They are not sent automatically.

The HelpDrawer support form can include diagnostics only when you choose to include them. Support logs remain a separate, deliberate action.