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.