How to Get an Email Alert When a Scheduled Website Screenshot Fails

To get an email when a scheduled website screenshot fails, configure an explicit failed-run alert and an email recipient in the screenshot scheduler. A visual-change alert is a different setting: it reports that two successful captures differ, and may not notify you when a capture cannot complete.

After enabling the alert, inspect the run history and check the failure threshold, repeat policy, and any automatic pause setting. These controls vary by provider. This guide uses documented provider examples; check the provider’s current documentation and plan before relying on a particular behavior.

1. Configure a failed-run alert

1. Choose a scheduler with documented failure notifications. Look specifically for failed-run or failed-snapshot alerts. A general claim of monitoring or email notifications does not establish that capture failures trigger email. Allscreenshots’ recurring screenshot guide documents failed-run alerts and email delivery. Site-Shot’s scheduled screenshots documentation describes schedule health and email after a specific streak of failures.
2. Create a schedule for the target page. Choose a capture cadence and rendering options suitable for the page. More frequent captures can reveal a problem sooner, but use more of the service’s screenshot quota. Allscreenshots says schedules are metered against monthly screenshot quota; available cadence and limits depend on its settings and plan.
3. Add an email destination. Enter the address that should receive alerts. Allscreenshots documents email and webhook destinations, which may be used together. Site-Shot documents notifications to the account email.
4. Enable the failure notification separately from change alerts. In Allscreenshots’ API example, the failure setting is alertOnFailure: true. Its change-only setting is separate. Do not assume a change notification will cover a failed capture.
5. Choose what happens after repeated failures. If supported, decide whether to keep trying, limit repeated emails, or automatically pause the schedule. Pausing can avoid a long stream of failures, but it also stops future attempts until someone resumes the schedule.
6. Run or inspect a capture and check history. Confirm that the schedule is active, that the recipient is correct, and that the history shows run status and available diagnostic details. Allscreenshots documents trigger-now and per-run history.

2. Understand the alert settings

Setting	What it tells you	What to verify
Failed-run alert	A scheduled capture did not complete successfully.	It is explicitly enabled and has a recipient or delivery route.
Change alert	Two successful captures differ visually.	Whether it is optional, and whether it is separate from failure alerts.
Failure threshold	How many failed attempts are needed before an alert or other action.	Whether notification is immediate or delayed by a streak threshold.
Repeat policy	Whether each failed run sends another message, or repeated messages are limited.	How and when alerts resume after the same failure persists or recovers.
Automatic pause	Whether a schedule stops after consecutive failures.	The configured threshold and how to resume it; do not assume this setting exists or has a standard value.
Run history	Which attempts ran, their status, and any available capture or reason.	That the alert links to useful details or that the schedule page retains them.
Delivery route	Where notifications go: email, webhook, or both.	That each destination is configured and reachable.

These controls are provider-specific. For example, Allscreenshots’ sample API configuration sets autoPauseAfterFailures to 5; that is a sample value, not a universal default. Site-Shot documents pausing and emailing after fourteen failed windows in a row. Calibre documents a different policy for snapshot failures: at most three consecutive emails for the same test failure, followed by a recovery confirmation after success. These examples should not be treated as interchangeable service guarantees. See Allscreenshots’ guide, Site-Shot’s documentation, and Calibre’s email notification documentation.

3. Set up an example using the Allscreenshots API

The documented Allscreenshots schedule example uses a failure-alert flag and supports delivery destinations and optional automatic pausing. The excerpt below shows the relevant settings from its guide; it is not a complete request, since the required endpoint, authentication, and other schedule fields must come from the current API documentation.

{
  "alertOnFailure": true,
  "autoPauseAfterFailures": 5
}

Use the actual API endpoint and required schedule fields from the provider’s current guide. Configure your recipient under its documented delivery options. If email and webhook delivery are both configured, decide which channel is the primary alert and ensure your webhook receiver handles retries or duplicate events safely.

4. Diagnose failures and alert delivery

Symptom	Likely cause	What to check or do
No email after a failed capture	Only change notifications are enabled, failure alerts are off, or no recipient is configured.	Enable the distinct failed-run setting, verify the delivery address, and inspect the failed run in history.
Email arrives only after several failures	The provider uses a consecutive-failure threshold or batches repeated notices.	Check the documented threshold and repeat policy. Decide whether the delay is acceptable for the page’s importance.
Schedule stopped sending alerts	It may have auto-paused after reaching its configured failure streak.	Check whether it is paused, investigate the last failed run, and resume it after addressing the cause.
Alert arrives but gives little detail	The email may summarize the event while details remain in run history.	Open the schedule history and inspect status, capture, and any available failure reason. Prefer a service whose failure notice or history identifies the affected page and profile.
Webhook notification does not produce an email	A webhook delivers an event to your endpoint; it does not itself send email unless your receiver implements that step.	Check endpoint reachability and logs, then have the receiver validate the event and send email through your chosen mail system. The cited provider guide documents webhook delivery but does not prescribe an email provider.
Too many emails for a persistent outage	The service may notify on every failed window and lack a repeat limit.	Look for a repeat limit, a failure threshold, or auto-pause. If unavailable, use a webhook receiver to apply your own deduplication and escalation policy.
Schedule appears enabled but is overdue	Enabled status does not necessarily mean recent captures are succeeding.	Review health and last-run status as separate signals. Site-Shot explicitly distinguishes schedule state from schedule health.

5. Keep the alert useful and reliable

• Test the complete path. Confirm the scheduler creates a run, the failure condition is recorded when applicable, and the notification reaches the intended inbox or webhook receiver. Use the service’s supported trigger or test mechanism rather than deliberately breaking a production page.
• Keep a diagnostic route. Email is useful for awareness; run history is needed to investigate. If using webhooks, retain enough event and delivery information to trace a missing notification.
• Choose a sensible cadence. Faster schedules can shorten detection time but consume more quota. Check quota and schedule limits for the selected service and plan.
• Set failure handling deliberately. A high threshold can reduce noise but delay awareness. Automatic pausing can stop repeated failed work but can also leave monitoring inactive until someone resumes it.
• Review the policy after recovery. Verify whether alerts stop after success, whether the schedule resumes automatically, and whether a pause must be cleared manually.
• Do not treat change detection as uptime monitoring. A page may fail to load or render before there is a valid image to compare. Configure a failure alert for that separate condition.

Or skip the browser setup

If you also need screenshots on demand or in an application, ScreenshotNeo provides a website screenshot API and an MCP server. Its one-call capture returns an image or PDF; this request captures the page at Stripe 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 and response details. Cookie banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

Sign up for ScreenshotNeo’s free plan.

Frequently asked questions

Will a screenshot change alert tell me when the capture fails?

Not necessarily. A change alert compares successful captures; configure a distinct failed-run alert for capture failures.

Should I use email or a webhook?

Use email for a direct notification. A webhook is useful when you need to route events into a system you control; sending email from it requires your receiver to implement that workflow.

Is there a standard number of failures before a schedule pauses?

No. The threshold and whether pausing is supported depend on the provider and its configuration.

Can an alert tell me why the screenshot failed?

Sometimes the email includes a reason; otherwise, check the schedule’s run history. Available diagnostics differ by service.