Skip to main content

​
What this is

Source alerts are the daily email notifications Zeotap sends to subscribed users when one of your sources has a data problem — no file arrived, ingestion failed for a large share of records, or a file has been in progress for a long time. Each email lists the affected source IDs and the failure reason, so you can diagnose whether the issue sits on the sending side (your export, your API, your file drop) or on the ingestion side. This page explains how to subscribe, what each alert scenario means, and how to respond when one lands in your inbox.

​
Prerequisites

Source alerts are opt-in. Only users on a subscription list receive them; a source failure will not surface as an alert email until at least one address is subscribed for your organisation. To subscribe or update the list, contact the Zeotap support team with the email addresses that should receive the alerts.

​
Subscribe to source alerts

To start receiving alerts, send a request to support@zeotap.com that includes:
  • The email addresses to add to the alert list.
  • The alert types you want to receive (see the four supported types below).
  • The time of day, as a single hour in your organisation’s local time, at which the daily digest should arrive.
  • For ingestion failures, the failure-rate threshold at which you want to be alerted. The default fires when more than 20% of the records in a file or streaming batch fail within 24 hours.
The four supported alert types are:
DELAYED_INGESTION_FAILURE is not enabled by default. Ask for it explicitly in your subscription request if you want to be alerted when files stay in progress for more than 48 hours.

​
Alert scenarios you will receive

Each alert email groups the failed sources by scenario. Use the source IDs in the email to open the affected sources from the Sources application and cross-check status, last-ingested time, and record counts before you start troubleshooting.

​
Why this happens

​
Respond to a source alert

Work through the subsection that matches the scenario in the email.

​
A. NO_DATA

  1. Confirm on your side that the expected file was generated for the scheduled date. If no file was generated, this alert is expected — no Zeotap-side action is required.
  2. If a file was generated, verify that it was dropped at the exact path the source is configured to read (bucket, folder, file-name pattern).
  3. If the file is present at the expected path but the alert fires again the next day, contact Zeotap support with the source ID and the file path.

​
B. PULL_FAILURE

  1. Confirm your source (BigQuery, CRM, storage bucket, or another pull-based integration) produced data for the scheduled window. If your upstream pipeline did not run, no Zeotap-side fix is possible — re-run the upstream job.
  2. If your data is present, verify Zeotap still has access to the source: check that credentials have not been rotated, that any IP allow-list still includes Zeotap, and that storage or API permissions have not changed.
  3. If credentials and access are intact and the next scheduled sync still fails, contact Zeotap support.

​
C. INGESTION_FAILURE

The error log for a failing source is written to Cloud Storage under the source’s ID:
  1. Open the error log for the affected source. The log names the field, record, or record range that failed and the validation reason (schema mismatch, missing required field, malformed timestamp, and similar).
  2. Fix the underlying data problem in the sending system and re-drop the file. Zeotap re-ingests the corrected records on the next scheduled sync.
If the same field fails across many files, the fix is a mapping change, not a re-drop. Correct the mapping for the source before re-sending, so the corrected file ingests cleanly on the first attempt.

​
D. DELAYED_INGESTION_FAILURE

This alert fires when a file has been in progress for more than 48 hours. There is no self-serve action to unblock a delayed ingestion.
Contact Zeotap support with the source ID, the file name, and the time the file was dropped. Support investigates the delay and updates the ticket with next steps.

​
Verify your alert subscription is working

After subscribing, confirm alerts are reaching the intended inboxes:
  1. Confirm at least one subscribed recipient received the daily digest at the requested hour on a day when a subscribed source had a known failure.
  2. Cross-check the source IDs in the email against your Sources list. Every ID in the email corresponds to a source you can open from the Sources application. If an ID does not resolve, the subscription is scoped to a different organisation — contact support to correct it.
  3. If a source has been paused for ingestion, alerts for that source are suppressed. You receive one confirmation alert when the source is resumed, and then normal alerting continues.

​
When to contact support

Contact Zeotap support if:
  • You subscribed but no alert arrived after two full days that included a known failure.
  • An alert lists a source ID that does not appear in your organisation.
  • A DELAYED_INGESTION_FAILURE alert has fired and the file is still in progress 24 hours later.
  • An INGESTION_FAILURE alert continues to fire for the same source after you have corrected the data and re-dropped the file across two subsequent sync cycles.
Include in your request:
  • The source ID, plus the file name for batch sources.
  • The alert type from the email (NO_DATA, PULL_FAILURE, INGESTION_FAILURE, or DELAYED_INGESTION_FAILURE).
  • The date and time of the alert email.
  • For ingestion failures, a copy of the error-log entries you inspected.

​
FAQ

Alerts are suppressed while a source is in a Paused or Paused (Ingestion) state. Recurring failure, overdue, and pull-stuck alerts do not send for paused sources; a single confirmation alert sends when the source is resumed.
Source alerts are delivered as a single daily digest at the hour configured for your organisation. To change the delivery hour, contact Zeotap support.
No. The email lists the affected source IDs and the scenario (NO_DATA, PULL_FAILURE, INGESTION_FAILURE, or DELAYED_INGESTION_FAILURE). For INGESTION_FAILURE, the failing records are written to the source’s error log in Cloud Storage under <source-id>/error-log/.
Not from the Zeotap UI today. Send the updated recipient list to Zeotap support and the subscription is updated for your organisation.

​
Next steps

Configure who receives these alerts, and the thresholds and filters that control when they fire, in Alerts & Notifications under Admin. The following are the error scenarios notified in the report:
Last modified on September 11, 2026