The Settings page is where you configure application-wide defaults for your local Siteimp workspace. These settings do not replace website-specific choices. They act as the baseline Siteimp can use when an individual website has not chosen its own crawl behavior or notification routing.
That distinction matters. Settings are the bottom layer of the preference stack. A website can still define its own crawl overrides. Monitoring notification links can also choose their own Slack or Discord destinations for a specific website. The settings on this page are the fallback values Siteimp uses when a more specific website-level choice is not available.
In practice, this page is for calm defaults: how gently Siteimp should crawl by default, and where user-owned monitoring notifications should go by default.
What this page is for
The Settings page answers two app-level questions:
- What crawl behavior should Siteimp use when a website does not define its own crawl overrides?
- What notification destination should Siteimp use when a website does not define its own monitoring notification links?
This keeps the app predictable without forcing every website to repeat the same configuration.
What you can do here
Configure app crawl defaults
The App crawl defaults section controls the default crawl policy for the application.
These values apply when a website does not define its own crawl overrides. Individual websites can still use their own settings later, so changing app crawl defaults does not mean every website must behave the same way forever.
The app crawl defaults can include:
- crawl delay
- crawl jitter
- max concurrency
These values are part of Siteimp’s politeness model. They help control how quickly Siteimp sends requests while scanning a site.
Configure app notification preference
The App notification preference section controls application-wide defaults for user-owned monitoring notifications.
This is where you can enable or disable app-level monitoring notifications and choose default destinations for:
- alert events
- recovery events
Notification destinations are user-owned Slack or Discord webhooks. They are used for monitoring notifications only.
A website can still use its own notification links. The app-level defaults are used only when a website does not provide a more specific destination.
App-level defaults versus website-level settings
Siteimp uses a preference cascade.
For crawl behavior, the order is:
- website-specific crawl override, when one exists
- app crawl default
- built-in fallback behavior
For monitoring notifications, the order is:
- website notification links first
- application default second
- no notification if no destination is available
This lets you set practical defaults once, then customize individual websites only when they need different behavior.
For example, most websites might use the same crawl delay and jitter. A slower or more fragile site can still use a website-specific override without changing the rest of your workspace.
The same idea applies to notifications. You might send most monitoring alerts to a general operations Slack channel, while one important website sends alerts to a specific Discord channel instead.
App crawl defaults
The App crawl defaults card summarizes the current default crawl behavior. When the card is closed, it shows the current delay, jitter, and concurrency values.
Choose Show settings to edit the values.
Crawl delay
Crawl delay is the minimum wait between requests before jitter is applied.
A larger delay makes scans gentler but slower. A smaller delay can make scans finish sooner, but may be less appropriate for small, slow, or sensitive sites.
Crawl jitter
Crawl jitter adds random extra delay per request.
Jitter helps avoid sending requests in an overly mechanical pattern. It is a small politeness tool that makes crawl timing less rigid.
Max concurrency
Max concurrency controls how many crawl requests can run at the same time.
A value of 1 is the safest polite default because Siteimp sends only one crawl request at a time.
Built-in defaults
If app crawl default fields are unset, Siteimp can fall back to its built-in values. The page describes the built-in defaults as:
- delay
0 ms - jitter
0 ms - concurrency
1
These built-in values keep Siteimp usable even before you customize anything.
App notification preference
The App notification preference card summarizes the current app-level notification defaults.
When the card is closed, it shows whether monitoring notifications are enabled and which default destinations are selected for alert and recovery events.
Choose Show settings to review or change the notification configuration.
Monitoring notifications enabled
This setting controls whether monitoring events can use the app-level default notification destinations.
When enabled, monitoring events can use these defaults if a website does not have its own notification links.
When disabled, app-level defaults will not be used for monitoring notifications.
Default alert destination
The default alert destination is used when a monitoring target has an alert condition and the website does not choose its own alert destination.
For example, this might be a Slack channel for operations alerts.
Default recovery destination
The default recovery destination is used when a monitoring target recovers and the website does not choose its own recovery destination.
This can be the same destination as alerts, or a different Slack or Discord channel if you prefer to separate problem reports from recovery messages.
Notification destinations
A notification destination is a user-owned Slack or Discord webhook destination.
To add one, open App notification preference, then use Add notification destination.
A destination includes:
- label
- provider
- enabled state
- webhook URL
The label should be something you will recognize later, such as Operations Slack, Client alerts, or Monitoring Discord.
The provider can be Slack or Discord.
The webhook URL is saved locally and used by Siteimp when sending monitoring notifications.
Enabled and disabled destinations
A destination can be enabled or disabled.
Enabled destinations can receive monitoring notifications.
Disabled destinations stay saved but will not receive notifications. This is useful when you want to keep a destination for later without deleting or recreating it.
How to use this page
A good default setup flow is:
- Open Settings.
- Review App crawl defaults.
- Leave the crawl defaults alone unless you know you want a different app-wide baseline.
- Open App notification preference.
- Add a Slack or Discord destination if you want monitoring notifications.
- Choose default alert and recovery destinations.
- Save notification defaults.
- Customize individual websites later only when they need different behavior.
This lets you keep the app simple at the global level while preserving detailed control for specific websites.
When to change app crawl defaults
Change app crawl defaults when you want most websites in your workspace to use a different baseline crawl behavior.
Useful reasons include:
- you prefer gentler scans by default
- you work mostly with small websites
- you want more spacing between requests
- you want every new website to start from a cautious crawl policy
Do not use app defaults for one unusual website. Use a website-level crawl override instead.
When to use website-level crawl overrides
Use website-level crawl overrides when one site needs different behavior from the rest of your workspace.
Examples:
- a client site is slower than the others
- a staging site should be scanned more carefully
- a small server needs extra delay between requests
- one site should use stricter concurrency than your normal default
Website-level overrides let you tune a single website without changing the application-wide baseline.
When to change app notification defaults
Change app notification defaults when you want monitoring alerts and recoveries to use a normal destination across the app.
For example, you might choose one general Slack channel for most monitoring alerts and recoveries.
This is useful when you do not want to configure notification routing separately for every website.
When to use website-level notification links
Use website-level notification links when a specific website should notify a specific Slack or Discord destination.
Examples:
- one client gets their own Discord channel
- production alerts go to a different Slack channel than personal projects
- recovery messages should go somewhere quieter than outage alerts
- one website should not use the app default destination
Website-level notification links come first in the routing order. App defaults are only the fallback.
Troubleshooting
App crawl defaults not saved
If app crawl defaults are not saved, check the values in the crawl settings fields.
Delay and jitter must be whole numbers and must be 0 or higher. Concurrency must be a whole number and must be 1 or higher.
After correcting the values, try saving again.
Crawl settings not saved
This message means Siteimp could not save the crawl settings change.
Review the error shown in the app, check that the values are valid whole numbers, and try again. If the problem continues, contact support and include what values you were trying to save.
Notification defaults not saved
If notification defaults are not saved, Siteimp could not update the application-wide monitoring notification preference.
Check that any selected default destinations still exist and are available. Then try saving again.
Notification destination not added
If a notification destination is not added, check the destination form.
The destination needs:
- a label
- Slack or Discord as the provider
- a webhook URL
If the webhook URL is missing or invalid, Siteimp cannot create a usable destination.
No notification destinations yet
This means no user-owned Slack or Discord webhook destinations have been added yet.
Add a destination before choosing app-level alert or recovery defaults.
No default selected
This is not always an error. It means Siteimp does not currently have an app-level default destination for that notification type.
If a website has its own notification links, those can still be used. If the website does not have its own destination and no app default is selected, no notification is sent for that event.
Where to go next
After configuring Settings, the next step depends on what you changed.
If you changed crawl defaults, open a website dashboard and review whether that website should use the app default or its own crawl override.
If you added notification destinations, open Monitoring or a specific website’s monitoring page to review how monitoring events should be routed.
The Settings page gives Siteimp its baseline. Website pages decide when that baseline is enough and when a specific site needs its own rules.