Website monitoring

The Website monitoring page is the monitoring control room for one website. It shows current health, lets you turn monitoring on or off, manages the exact URLs Siteimp checks, explains target-level robots.txt policy, and records the fact table of recent monitoring results.

This page is different from the main Monitoring page. The main Monitoring page shows a workspace-wide list of websites. This page is narrower and more useful when you want to understand or change monitoring behavior for one specific site.

Monitoring is target-based. A website can have one target or many targets. Each target is evaluated against the website's current robots.txt policy before Siteimp checks it. This matters because the same robots.txt file can allow one target and block another.

Siteimp also protects active scans. When any scan is queued or running, scheduled monitoring pauses so the scan can use the app's crawling, Lighthouse, media, external-link, artifact, and database work without competing against background monitoring checks. Monitoring resumes automatically after active scans finish, fail, or are cancelled.

What this page is for

Use this page when you want to answer questions like:

• Is this website healthy right now?
• Is monitoring turned on for this website?
• How often is Siteimp checking it?
• Which URLs are being checked?
• Does robots.txt allow each monitoring target?
• When was the monitoring robots policy last checked?
• Are failures happening now, or did they happen earlier?
• Where do alert and recovery notifications go?
• How many monitoring result rows are stored?
• Should old monitoring data be pruned?

Siteimp treats monitoring as a website-level feature with target-level evidence. Each website can have its own monitoring settings, targets, notification routing, and stored result history.

Page header

The top of the page identifies the website and shows its main monitoring context:

• website name
• start URL
• registrable domain
• current monitoring health badge

The page actions are:

• Back, which returns to the Monitoring overview
• Refresh, which reloads monitoring summary, signals, notifications, ownership state, and maintenance state
• Run monitoring now, which immediately runs monitoring checks for this website when monitoring is enabled and no scan is active

The Run monitoring now button is useful when you do not want to wait for the scheduler. It performs a manual monitoring pass, then refreshes the page when the run completes.

If a scan is queued or running, Siteimp does not start a manual monitoring run. This prevents monitoring from competing with an active scan. Wait for the scan to finish, fail, or be cancelled, then run monitoring again.

Overview cards

The overview cards summarize the current monitoring state for this website.

Overall status

The Overall status card tells you whether Siteimp currently considers the website healthy, failing, unknown, or not monitored.

When monitoring is enabled, this status is derived from the latest enabled target results. When monitoring is off, the page reports that monitoring is off rather than pretending the website is healthy.

Stored results

The Stored results card shows how many monitoring result rows are stored for this website.

A result row is one monitoring check result. It is not the same thing as one target. A target using the both check mode can create separate ping and fetch result rows.

Retention

The Retention card shows the current monitoring retention window in days.

This retention setting is app-wide and affects monitoring data for all monitored websites, even though the summary is displayed here for convenience.

Monitoring settings

The Monitoring settings section controls whether this website is monitored and how failure state is calculated.

When the section is closed, it summarizes the current settings, such as:

On • every 5 minutes • threshold 1

Open Edit settings to change the details.

Turn monitoring on or off

Use Turn on or Turn off to enable or disable monitoring for this website.

When monitoring is off, Siteimp does not run scheduled checks for this website. When monitoring is on, Siteimp checks the configured targets according to the monitoring interval and scheduler behavior.

Scheduled checks still pause while a scan is queued or running. This pause applies even when monitoring is turned on.

Interval minutes

Interval minutes controls how often this website should be checked.

Siteimp wakes on a regular scheduler cadence and runs websites that are due. The field describes the target interval, while the exact run time can depend on when Siteimp is awake and when the scheduler loop reaches the website.

Monitoring pauses during scans

Siteimp pauses scheduled monitoring while any scan is queued or running. This is intentional. Scans are heavier than monitoring because they may crawl pages, run Lighthouse, check media, validate external links, write artifacts, and update several database tables.

Pausing monitoring during scans keeps scan results more stable and prevents background checks from competing with scan work. Existing monitoring results stay available while the scan runs. New scheduled monitoring results resume automatically after there are no active scans.

Manual monitoring runs follow the same rule. If you choose Run monitoring now while a scan is active, Siteimp waits instead of starting monitoring work.

Failure threshold

Failure threshold controls how many failed checks should count before a target is treated as failing.

A threshold of 1 makes monitoring sensitive. A higher threshold makes Siteimp wait for repeated failures before the target is treated as failing. This can be useful for sites that occasionally return temporary errors but recover quickly.

Targets

The Targets section controls which URLs Siteimp checks for this website.

A target is a URL under the website's base URL. Targets stay under the current website. To monitor a different website, add it as a separate website first.

When the section is closed, Siteimp summarizes the number of targets, the number currently failing, and the most recent known robots policy timing. For example:

1 target • 1 failing
Robots policy checked just now

For multiple targets, the closed summary may say that robots policies were checked recently, or that only some target policies have been checked.

Adding a target

To add a target:

1. Open Manage targets.
2. Enter a target path, such as /about.
3. Review the final target preview.
4. Review the target-level robots policy preview.
5. Choose a check mode.
6. Decide whether the target starts enabled.
7. Choose Add target.

The page shows a Final target preview before you save. This helps confirm which URL Siteimp will monitor.

Target path

The target path is appended to the website's base URL.

For example, if the website base is:

https://formimp.com

and the path is:

/about

then the final target is:

https://formimp.com/about

Leaving the path blank targets the base URL itself.

Target-level robots policy

Monitoring uses target-level robots policy. Siteimp checks the relevant robots.txt file and evaluates the specific target URL, not just the website start URL.

That means two targets on the same website can have different monitoring outcomes:

/
  Monitoring allowed

/private
  Ownership required

/admin/help
  Monitoring allowed

Siteimp uses the same policy language across scan setup and monitoring:

• Monitoring allowed means no applicable robots block was found for the target.
• Siteimp hard block means the User-agent: Siteimp group disallows this target. Owner override does not bypass this.
• Ownership required means the wildcard group disallows this target and owner override is not active.
• Owner override active means the wildcard group disallows this target, but verified owner override is active.
• Robots unavailable means Siteimp could not preview the policy right now. Monitoring checks robots policy again before running.
• Needs review means the file was fetched, but the preview could not interpret it cleanly.

Siteimp hard block

A Siteimp hard block is created by a User-agent: Siteimp rule that disallows the target.

For example:

User-agent: Siteimp
Disallow: /

This is the direct way for a site owner to tell Siteimp not to access the site. Owner override does not bypass a Siteimp-specific block.

Ownership required for wildcard blocks

A wildcard block is created by a User-agent: * rule that disallows the target.

For example:

User-agent: *
Disallow: /

Siteimp respects wildcard blocks by default. If you own or control the site, you can verify ownership and enable owner override. Owner override applies to wildcard blocks only. It does not bypass a Siteimp hard block.

Robots policy timing

The target robots policy display shows when the policy was checked. This helps explain cases where a recently changed robots.txt file has not yet appeared in the monitoring UI or recent check results.

You may see messages such as:

Policy checked just now
Policy checked 8 minutes ago
Policy checked Sep 14, 2026, 10:13 a.m.

Monitoring may reuse a recent robots.txt response for targets on the same origin. This reduces repeated requests to /robots.txt, especially when several targets share one website. If robots.txt changed very recently, monitoring may briefly reflect the previous policy until the cached policy expires and Siteimp checks it again.

Check mode

A target can use one of three check modes:

• ping
• fetch
• both

A ping check is lightweight. A fetch check records a fuller fetch result. A target set to both produces separate ping and fetch result rows.

Enabled

An enabled target can be checked by monitoring. A disabled target remains saved but does not participate in active monitoring.

Target table

The target table shows each configured target with:

• target URL
• mode
• enabled state
• current status
• target-level robots policy
• robots policy timing
• last monitoring check time
• status code
• response time
• latest error
• delete action

You can adjust a target's mode or enabled state directly from the table.

Deleting a target also deletes its stored result rows, so use that action when you no longer want Siteimp to keep monitoring history for that target.

Current failures

The Current failures section shows whether anything is broken right now.

This area is intentionally separate from the recent results table. Current failures answer a present-tense question: “What is failing now?” Recent results answer a historical question: “What checks have happened recently?”

When the section is closed, it summarizes current state, such as:

• monitoring is off
• nothing is failing right now
• one or more current failures exist

Open Show details to inspect the latest failure signals.

If there are no current failures, the page says so directly. That does not mean there were never failures in the past. It means Siteimp does not currently see a failing latest check for this website.

Recent results

The Recent results section is the fact table.

Each row is one monitoring check result, not one monitoring target. This matters because a target using both creates separate rows for ping and fetch.

The table can show:

• checked time
• target
• check type
• requested URL
• final URL
• status code
• response time
• error

Use this table when you want to understand what Siteimp actually observed during recent monitoring checks.

Robots blocked results

robots_blocked is a monitoring result, not a network failure.

It means Siteimp skipped the check because robots policy said the target should not be accessed. In the recent results table, a robots_blocked row may show:

• status code 0
• response time 0 ms
• no final URL
• error robots_blocked

That combination means Siteimp did not fetch the target. It recorded that the check was skipped because of robots policy.

Use the Targets section to understand the current robots policy for the target. The target row shows whether the current policy is a Siteimp hard block, a wildcard block that requires ownership, or an allowed target.

If you recently changed robots.txt, remember that monitoring may briefly show or record the previous policy while the robots policy cache is still fresh.

Notifications

The Notifications section controls whether this website can send monitoring notifications and where alert and recovery messages go.

This section only appears when monitoring is enabled for the website.

There are two levels to understand:

1. App notification defaults, configured in App settings.
2. Website notification overrides, configured here for this website.

Website overrides replace app defaults for this website. Choose Use app default to remove the website-specific override and return to app-level routing.

Website notifications

The Notifications enabled for this website checkbox controls whether this website is allowed to send monitoring notifications.

Even if app-wide notifications are enabled, this website can still disable its own monitoring notifications.

App notifications

The App notifications status shows whether app-wide monitoring notifications are enabled.

If app-wide monitoring notifications are turned off, website notification settings can still be saved, but delivery remains blocked until app notifications are enabled in App settings.

Alerts

Alerts are sent when monitoring starts failing.

For alerts, you can:

• use the app default
• choose an existing Slack or Discord channel
• create a new website-specific channel

Recovery

Recovery messages are sent when monitoring recovers.

Recovery routing works the same way as alert routing. You can use the app default, choose an existing channel, or create a new website-specific channel.

Effective destination

The Effective destination is the destination Siteimp will actually use after it applies the routing rules.

The routing order is:

1. website override
2. app default
3. no notification if no destination is available

This makes the page useful even when nothing is configured yet. It shows both what is selected and what Siteimp can actually send.

Retention and maintenance

The Retention and maintenance section keeps monitoring database maintenance nearby, but lower on the page so the operational view stays focused.

This section includes app-wide retention controls and pruning actions.

Retention days

Retention days controls how long monitoring result rows are kept.

This setting is app-wide. Changing it here affects all monitored websites, not only the website currently open.

Save retention

Use Save retention to update the app-wide retention window.

The value must be an integer greater than 0.

Reset to default

Use Reset to default to return monitoring retention to the built-in default.

Prune this website

Prune this website deletes old monitoring result rows for the current website using the current app-wide retention window.

Prune all old data

Prune all old data deletes old monitoring result rows across all websites using the current app-wide retention window.

Delete all results

Delete all results deletes every stored monitoring result row for every website.

This is intentionally the most destructive maintenance action. Siteimp asks for confirmation before deleting all monitoring results.

How to use this page

A good basic workflow is:

1. Confirm the website and health badge at the top of the page.
2. Review the overview cards.
3. Open Monitoring settings and turn monitoring on if needed.
4. Open Targets and confirm what Siteimp is checking.
5. Review target-level robots policy and policy timing.
6. Use Run monitoring now when you want an immediate check and no scan is active.
7. Review Current failures if the site is unhealthy.
8. Use Recent results when you need the check-by-check history.
9. Configure Notifications if you want alerts and recovery messages.
10. Use Retention and maintenance only when you need to manage stored result history.

Common states

Monitoring off

If monitoring is off, Siteimp is not checking this website for failures.

Turn monitoring on to start evaluating current health.

Healthy

Healthy means the latest enabled target results do not currently show a failure.

A healthy status does not mean old failures never happened. Check Recent results for history.

Failing

Failing means one or more enabled targets currently have failing latest results.

Open Current failures for the failure details, then check Recent results for the raw check history.

A failing target with robots_blocked is different from a failed network check. It means Siteimp obeyed robots policy and skipped the target.

Unknown

Unknown usually means Siteimp does not have enough recent monitoring data to make a confident current-health statement yet.

Run monitoring now or wait for scheduled checks to generate result rows. If a scan is active, monitoring resumes after the scan finishes, fails, or is cancelled.

Paused during a scan

Siteimp pauses monitoring checks while a scan is queued or running. This is not a target failure. It is a resource-protection rule that keeps scans from competing with background monitoring work.

When the scan is no longer active, Siteimp resumes scheduled monitoring on the next normal scheduler pass.

Troubleshooting

Interval minutes must be valid

The interval must be a whole number greater than 0.

Use a value like:

5

instead of a blank value, decimal, or negative number.

Failure threshold must be valid

The failure threshold must be a whole number greater than 0.

Use 1 for the most sensitive behavior, or a higher number if you want Siteimp to wait for repeated failures before treating a target as failing.

Target URL stays inside this website

Monitoring targets must stay under the current website's base URL.

Do not paste a full URL into the target path field. Use a path such as:

/about

To monitor another website, add it as a separate website first.

Website base URL is not available yet

This can happen if the website details are still loading. Wait for the page to finish loading, then try again.

Robots blocked

If a recent result shows robots_blocked, Siteimp skipped the target because robots.txt told it not to access that URL.

Open Targets and review the robots policy for the target. If the target shows Siteimp hard block, the site has a Siteimp-specific rule that blocks Siteimp and owner override does not bypass it.

If the target shows Ownership required, the wildcard group blocks the target. Verify ownership and enable owner override only for sites you own or control.

Siteimp hard block

A Siteimp hard block means the User-agent: Siteimp group disallows the target. Siteimp treats this as a hard stop.

Owner override does not bypass a Siteimp hard block. To allow Siteimp, the site owner needs to change the Siteimp-specific rule in robots.txt.

Ownership required for wildcard blocks

Ownership is required when the wildcard group blocks a target and owner override is not active.

Verify ownership and enable owner override only for websites you own or control. Owner override applies to wildcard blocks only.

Robots policy timing looks stale

Monitoring may reuse a recent robots.txt response for targets on the same origin. This helps avoid repeatedly fetching /robots.txt for every target.

If you changed robots.txt recently, wait for the policy cache to expire and check the target again. The policy timing shown in Targets tells you when Siteimp last checked or received the robots policy used by the preview.

Enter a channel name

When creating a new Slack or Discord channel, provide a readable channel name.

This label helps you recognize the destination later.

Enter a webhook URL

When creating a new Slack or Discord destination, paste the webhook URL for that channel.

Webhook URLs are used by Siteimp to send monitoring notifications.

Retention days must be valid

Retention days must be a whole number greater than 0.

This value is app-wide and affects all monitored websites.

Monitoring run failed

If a manual monitoring run fails, Siteimp could not complete the check pass for this website.

Review the error shown in the app, confirm monitoring is enabled, confirm at least one target exists, and try again.

If the error is robots_blocked, the monitoring run completed a policy skip for that target rather than a normal network request failure.

Monitoring is paused while a scan is running

Siteimp does not run monitoring checks while a scan is queued or running. This includes scheduled monitoring and manual Run monitoring now actions.

Wait for the scan to complete, fail, or be cancelled, then try the monitoring run again. This pause protects scan performance and keeps scan evidence from competing with background monitoring checks.

Monitoring target not added

If a target cannot be added, check that the target path is valid and stays under this website's base URL.

Do not use a full URL unless you are adding that URL as a separate website.

Monitoring target not updated

If a target cannot be updated, the saved target may not have accepted the new mode or enabled state.

Refresh the page, review the target row, and try the change again.

Monitoring target not deleted

If a target cannot be deleted, Siteimp could not remove the target and its stored result rows.

Refresh the page and try again. If the issue continues, contact support with the website name and target URL.

Notification settings not saved

If notification settings cannot be saved, check whether the selected destination exists, whether newly created channel fields are complete, and whether app-wide notifications are configured as expected.

Website notification settings can be saved separately from app defaults, but actual delivery still depends on a valid effective destination.

Retention setting not saved

If the retention setting cannot be saved, confirm the value is a whole number greater than 0, then try again.

Because retention is app-wide, changing it affects all monitored websites.

Where to go next

From this page, the next most common destinations are:

• Monitoring, to return to the workspace-level monitoring overview
• Website dashboard, to review ownership, scan history, and scan robots behavior for the same site
• App settings, to configure app-wide notification defaults

The website monitoring page is where monitoring becomes concrete. It turns a site-level health summary into specific checks, specific targets, specific robots policy decisions, specific notifications, and specific result rows.