ScreenshotNeo

BlogHow-to

Urlwatch Email Notifications Not Working: Common Fixes

Test urlwatch email delivery, then check reporter settings, SMTP authentication, scheduler access, and whether a change should have triggered a message.

By the ScreenshotNeo team4 October 20267 min read

If urlwatch email notifications are not arriving, first test the email reporter directly:

urlwatch --test-reporter email

If the test fails, inspect the email reporter configuration and rerun the command with --verbose. If it succeeds but scheduled notifications do not arrive, check what the scheduled run monitors, which configuration and credentials it can access, and whether the run produced a reportable event.

Urlwatch reports changes, new jobs, and errors by default. It does not report unchanged pages by default, so an absent email does not always mean delivery is broken. The official project describes urlwatch as a tool for watching webpage changes and receiving notifications by email, in the terminal, or through third-party services. See the urlwatch reporter documentation and configuration documentation.

1. Test email delivery directly

Run the reporter test from the same account and environment that normally runs urlwatch:

urlwatch --test-reporter email

The email reporter must be configured and enabled for this test. If you are unsure which configuration file urlwatch is using, open the configuration with:

urlwatch --edit-config

If the test does not work, repeat it with verbose logging:

urlwatch --test-reporter email --verbose

Read the resulting error as a clue about which layer failed. A connection or TLS error points toward server, port, or encryption settings. An authentication error points toward credentials or the provider’s current sign-in requirements. If the command reports success but the message is absent, check the destination address, spam handling, and provider-side filtering; the documentation cannot establish what happened inside a particular mail account.

2. Check whether this run should send an email

Use urlwatch --edit-config to review the display settings and the jobs being watched. By default, urlwatch reports changes, new jobs, and errors. Unchanged pages are left out unless unchanged: true is set in the display configuration.

Also check empty-diff. When it is false, a page can change while its filtered diff is empty, and urlwatch omits that change from the report. This can happen when filters remove the content that changed.

  • If you need an email for every run regardless of changes, review the documented unchanged-reporting setting.
  • If a page appears to change but no report is generated, inspect the job’s filters and the empty-diff setting.
  • If the run reports an error, verify that errors are included in the output and that the reporter is enabled.

Changing notification behavior can increase message volume. Prefer enabling unchanged reports only when you have a reason to receive a message on every run.

3. Verify reporter enablement, addresses, and method

Reporters are disabled by default. Check that the email reporter is under the report configuration and that its enabled option is set to true. Confirm the sender (from), recipient (to), and delivery method.

Urlwatch documents two email delivery routes:

Route Use it when Check
SMTP You have an SMTP service and credentials Host, port, authentication, TLS mode, sender, recipient, and credential availability
System sendmail Your host already has a working local mail transfer agent The sendmail command is installed, callable by the urlwatch user, and configured to deliver mail

A sendmail configuration still needs the reporter enabled and valid sender and recipient addresses. Switching methods will not fix a missing report event, an incorrect recipient, or a scheduled job that uses a different configuration.

4. Check SMTP server settings and credentials

Compare urlwatch’s SMTP values with the mail provider’s current requirements. The urlwatch documentation’s Gmail example uses smtp.gmail.com, port 587, authentication enabled, and STARTTLS enabled. Treat that as an example configuration, not a guarantee that it matches every account or provider policy.

Urlwatch documents a command to prompt for the SMTP password, check the login, and store the password in the keychain for later runs:

urlwatch --smtp-login

Run it as the same operating-system user that runs urlwatch. Then repeat the email reporter test. If the provider has changed its authentication rules, check its current instructions for supported credentials and SMTP access. Do not follow old advice to enable “less secure apps” without verifying that the provider still supports that setting.

5. Compare an interactive run with the scheduled run

If email works in a terminal but not from cron or another scheduler, compare the execution contexts. A scheduler may run as a different user, use a different working directory, load a different environment, or lack access to the configuration and stored keychain credentials. Urlwatch’s documentation notes that scheduler output depends on scheduler configuration and that keyring access can be unsuitable in cron.

  1. Find the exact command configured in the scheduler and run that command manually as the scheduled user.
  2. Confirm the scheduled command reads the intended urlwatch configuration and job list.
  3. Check that the scheduled user can access the same stored credentials and any required keychain service.
  4. Capture or inspect the scheduler’s standard output and error so urlwatch’s verbose diagnostic messages are visible.
  5. Run urlwatch --test-reporter email in that same execution context if possible.

Urlwatch documents insecure_password as a fallback when keyring use is not possible, but warns that storing a password in plaintext can expose it to software or other local users and may expose it in logs. The documentation advises against using a primary email account with this option and suggests a dedicated throwaway sending account or local sendmail instead. Treat this as a security tradeoff, not the preferred fix.

6. Troubleshoot common symptoms

Symptom Likely cause What to check
The test says the reporter is disabled or produces no test message Email reporter is not enabled or is not configured under report Enable the email reporter; check its method, sender, and recipient; rerun the test.
SMTP connection fails Incorrect hostname or port, unavailable server, or network restrictions Use the provider’s current SMTP hostname and port; confirm the host running urlwatch can reach the service.
TLS or encryption negotiation fails The configured TLS mode does not match the provider’s expected connection Compare the provider’s current requirements with the configured port and STARTTLS setting. The urlwatch Gmail example uses port 587 with STARTTLS.
SMTP authentication is rejected Wrong or unavailable credentials, or provider policy requiring another supported credential method Use urlwatch --smtp-login to check and store a login; verify current provider account requirements.
The test works in a shell but scheduled mail is missing Different user, environment, configuration path, or keyring access in the scheduler Run the scheduled command as its configured user; check its configuration and credential access; inspect scheduler output.
No email arrives after a normal urlwatch run No reportable change or error occurred, or the filtered diff is empty Check job output, display settings, unchanged, and empty-diff.
The test reports success but the recipient sees nothing Wrong recipient, spam handling, filtering, or delivery behavior outside urlwatch Confirm to and from; inspect spam and provider-side logs or filtering. Urlwatch’s test alone cannot verify inbox placement.
Sendmail method fails Local sendmail command or mail transfer agent is missing or not configured for the urlwatch user Verify the command exists and local mail delivery works for that user, then inspect its mail system logs.

7. Choose a delivery route after isolating the failure

Keep email if email is required and your SMTP service or local mail transfer agent works in the scheduled context. Choose SMTP when you already have a supported service and credentials; choose sendmail when the host already operates a working local MTA. If email is not required, urlwatch also documents reporters for services such as Matrix, Slack, Telegram, ntfy, Pushbullet, and Pushover. Your choice depends on existing infrastructure and the channel you need; the urlwatch documentation does not establish that a paid service is necessary.

8. Keep scheduled notifications reliable

  • Use one known urlwatch configuration and job list for both manual and scheduled runs.
  • Run the scheduler under an account that can read the configuration and access its credentials.
  • Keep diagnostic output available so a failed run can be distinguished from an unchanged page.
  • Test the reporter after changing SMTP settings or credential storage.
  • Review whether unchanged reports and filtered empty diffs match the notification volume you want.

Email delivery depends on the SMTP provider or local mail system, the scheduler’s environment, and the recipient’s mail handling. The official urlwatch guidance helps diagnose its reporter and configuration, but cannot verify provider account status, host-level SMTP blocks, spam placement, or recipient filtering.

9. Use ScreenshotNeo when you also need clean page captures

ScreenshotNeo is a website screenshot API and MCP server for developers, made by Yorker Media. It is not a urlwatch email reporter or a replacement for change alerts. If your workflow also needs a visual capture of a page—for example, to inspect the page that triggered a urlwatch change—ScreenshotNeo is the alternative to try first for that capture: cookie banners, newsletter popups, and chat widgets are removed before the screenshot, and only clean screenshots are billed. Learn more at ScreenshotNeo.

Or skip the browser setup

Make one GET request to capture a page as WebP:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

See the ScreenshotNeo API documentation for request options. The same call in Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

And in Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', new Uint8Array(await res.arrayBuffer()));

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, timeouts, and failed loads are never billed; response headers say which page verdict applied and whether it was billed. An MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. Sign up for 1,000 free screenshots a month with no card.

FAQ

Does urlwatch send an email every time it runs?

No. Unchanged pages are excluded by default. Enable unchanged reporting only if you want a message even when monitored pages have not changed.

Can I test SMTP without waiting for a page to change?

Yes. Use urlwatch --test-reporter email; it tests the configured email reporter independently of a monitored page changing.

Does successful test delivery prove scheduled delivery will work?

No. The scheduled process may use a different user, configuration, environment, or keyring access.

Can ScreenshotNeo send urlwatch notifications?

No. ScreenshotNeo captures webpages as images or PDFs; urlwatch remains responsible for monitoring changes and sending its configured notifications.