How to Alert or Open a Ticket When an Expected Client File Does Not Arrive

You alert or open a ticket when an expected client file does not arrive by building a file-arrival check that runs on a schedule, compares what was expected against what actually landed, and triggers a notification or creates a support ticket automatically when the file is missing or late. This guide is for data engineers and operations teams who depend on clients delivering files on a predictable schedule and need to catch late or missing deliveries before they cause downstream failures. By the end, you will have a monitoring pipeline that detects missing file delivery, fires an alert to your team, and optionally opens a ticket in your support or project management system without any manual checking.

Without this system, a missing file often goes unnoticed until someone asks why a report is stale or a downstream job failed with a zero-row source.

The Problem with Manual File Monitoring

Most teams discover a missing client file the wrong way: a downstream report shows no data, a pipeline run completes in seconds with zero rows loaded, or a client asks why their data is not reflected in the system yet. By that point, hours or days of processing time have been lost, and the root cause trace goes back to a file that never arrived.

Manual file checking, where someone logs into an SFTP server or S3 bucket each morning to verify deliveries, does not scale past a handful of clients. It also fails silently when the person checking is on leave, distracted, or simply forgets. Automating the missing file detection pipeline removes the human dependency entirely and shifts the team from reactive to proactive.

What You Will Need Before Starting

• The delivery location for each expected file (SFTP path, S3 bucket and prefix, Azure Blob container, or similar)
• The expected delivery schedule for each client file (daily at 6am, weekly on Monday, monthly on the 1st)
• A grace period per file (how many minutes or hours past the expected time before the file is considered late)
• A notification destination (email address, Slack channel, PagerDuty service, or a ticketing system such as Jira or ServiceNow)
• An ETL or orchestration platform that supports scheduled pipelines and conditional branching (Integrate.io handles file-arrival checks and conditional alerting natively)

How to Alert When an Expected Client File Does Not Arrive: Step-by-Step

Step 1: Build a File Inventory for Each Expected Delivery

Before you can detect a missing file, you need a precise definition of what you are expecting. A file inventory gives the monitoring pipeline something concrete to check against rather than relying on pattern matching at runtime.

What to do:

• Create a reference table in your database or a configuration file with one row per expected delivery; include the client name, the expected file path or naming pattern, the delivery location (SFTP host and directory, S3 bucket and prefix), the expected delivery time, and the grace period in minutes
• For files that use a date stamp in the filename (for example, a file named with the current date in YYYYMMDD format), store the naming pattern separately from the static path prefix so the monitoring pipeline can construct the expected filename dynamically at runtime
• Assign a severity level to each expected file: high severity for files that block a downstream pipeline, medium for files that feed a daily report, low for files that are supplementary; this determines whether a missing file opens an urgent ticket or sends a standard notification
• Review the inventory with your operations team before activating monitoring; gaps in the inventory mean missed deliveries that no alert will catch

Output of this step: A complete file inventory table listing every expected delivery with its path pattern, schedule, grace period, and severity level.

Step 2: Build a Scheduled File-Arrival Check Pipeline

The monitoring pipeline runs on a schedule that matches or slightly trails the latest expected delivery time across all clients. Its job is to check each row in the file inventory, determine whether the expected file has arrived, and pass the result to the next step for alerting.

What to do:

• Schedule the monitoring pipeline to run after the latest grace period window across all clients; if your latest expected file has a grace period ending at 8am, run the monitoring pipeline at 8:05am
• For each row in the file inventory, have the pipeline connect to the delivery location and check whether a file matching the expected path or naming pattern exists and has a last-modified timestamp that falls within the expected delivery window (not just today, but within the expected time range for today's delivery)
• Record the result of each check as a row in a file arrival log table: client name, expected file, check timestamp, status (arrived or missing), actual filename if found, and actual arrival time if found
• For files with date-stamped names, construct the expected filename at runtime using today's date in the stored naming pattern before running the existence check

Output of this step: A file arrival log table updated after every monitoring run, with a current status row for each expected delivery.

Where Integrate.io helps: Integrate.io's file connector can check for the existence of files at an SFTP or S3 location and return file metadata including last-modified timestamps. Combined with a scheduled pipeline trigger, this makes the file-arrival check a configuration task rather than a scripting task.

Step 3: Identify Missing and Late Files from the Arrival Log

With a populated file arrival log, the next step is to query it for actionable results: files that are definitively missing (grace period has passed, no file found) versus files that are early in their grace period (not yet overdue). Only the former should trigger an alert.

What to do:

• Query the arrival log for rows where the status is missing and the current time is past the expected delivery time plus the grace period; these are confirmed late deliveries, not just files that have not arrived yet
• Exclude files that arrived late in a previous run but have since been delivered; a file that landed 30 minutes after its grace period expired should clear its alert once it arrives, not keep triggering notifications
• Group the missing file results by severity level so high-severity missing files can be routed to an urgent notification channel and low-severity files to a digest summary
• Check for files that arrived but are suspiciously small (near-zero bytes) or have an unexpected file size compared to historical deliveries; an empty file that technically arrived is functionally the same as a missing file

Output of this step: A filtered list of confirmed late or missing files grouped by severity, ready to trigger notifications and tickets.

Step 4: Send an Alert for Each Missing File

With the confirmed missing file list in hand, the pipeline sends a notification for each item. The alert should contain enough information for the recipient to act immediately, without having to look anything up.

What to do:

• For each missing file, compose an alert message that includes: the client name, the expected filename or pattern, the delivery location, the expected delivery time, how long overdue the file is, and the severity level
• Route high-severity alerts to a direct channel (Slack direct message to the on-call engineer, PagerDuty incident, or an email with a high-priority flag) and standard-severity alerts to a shared team channel or a daily digest
• Include a direct link to the delivery location in the alert so the recipient can check the folder immediately without navigating manually
• Avoid sending duplicate alerts for the same missing file across multiple monitoring runs; track which missing files have already been alerted in the arrival log using an alerted flag, and only send a new alert if the file is still missing and no alert has been sent in the current delivery window

Output of this step: Alert messages sent to the appropriate channel for each confirmed missing file, with deduplication so each missing file triggers one alert per delivery window.

Where Integrate.io helps: Integrate.io's pipeline notifications can send email or webhook alerts at the end of a pipeline run based on conditional logic. By connecting the missing file output to a webhook step, you can post directly to a Slack channel or trigger a PagerDuty event with a fully composed message, without leaving the pipeline configuration.

Step 5: Open a Ticket for High-Severity Missing Files

An alert gets attention; a ticket assigns ownership and creates an audit trail. For high-severity missing files, opening a ticket automatically in your support or project management system ensures someone is formally accountable for resolving the delivery gap.

What to do:

• For each high-severity missing file identified in Step 3, call your ticketing system's API to create a new ticket; include the client name, expected file details, delivery location, time overdue, and a link to the file arrival log for context
• Set the ticket priority to match the severity level from the file inventory; a file that blocks a downstream pipeline should open a high or urgent priority ticket, not a normal one
• Assign the ticket to the client success or data operations team member responsible for that client; include this assignment in the file inventory so the pipeline can set it automatically rather than leaving the ticket unassigned
• Check whether an open ticket already exists for this client's missing file before creating a new one; duplicate tickets for the same delivery window create noise and confusion; use a ticket reference field in the arrival log to track open tickets per delivery

Output of this step: A ticket opened in the team's ticketing system for each high-severity missing file, with priority, assignment, and delivery context pre-populated.

Step 6: Resolve and Log When the File Eventually Arrives

Alerting on missing files is only complete if the system also recognizes when the file eventually lands and closes the loop. Without a resolution step, the arrival log accumulates stale missing-file records and the team loses confidence in the monitoring output.

What to do:

• Run the file-arrival check pipeline again after each subsequent monitoring interval and update the arrival log status from missing to arrived when the file is found, recording the actual arrival time and the delay in minutes
• For files that arrived late, calculate and log the delay so you can track delivery reliability per client over time; a client whose files are consistently 30 to 90 minutes late needs a grace period adjustment, not repeated alerts
• If a ticket was opened in Step 5, update it automatically when the file arrives: post a comment with the actual arrival time and close or resolve the ticket so the team does not follow up on a delivery that has already been resolved
• Send a resolution notification to the same channel that received the original missing-file alert; teams that receive a "file missing" alert and never receive a "file arrived" follow-up lose track of whether the issue was resolved

Output of this step: Arrival log updated with resolution status, open tickets closed or commented, and a resolution notification sent to the original alert channel.

Common Mistakes to Avoid

• Alerting before the grace period expires: Firing an alert the moment a file is one minute late generates noise that trains the team to ignore alerts. Always build in a grace period per file and only alert after it has passed.
• Not deduplicating alerts across monitoring runs: A monitoring pipeline that runs every 30 minutes and sends a new alert each time for the same missing file will flood a Slack channel within hours. Track alerted status in the arrival log and suppress repeat alerts within the same delivery window.
• Using only filename existence as the arrival check: A file that arrived with zero bytes, or a file from two days ago that was never deleted, will pass an existence check while still failing the actual delivery requirement. Always check file size and last-modified timestamp alongside existence.
• Leaving ticket assignment blank: An auto-opened ticket with no assignee sits in a backlog until someone notices it. Map each client in the file inventory to a named owner and set the assignment at ticket creation time.
• Never reviewing grace periods: A grace period set at onboarding rarely stays accurate as clients change their export processes. Review grace periods quarterly against the actual delivery time distribution in the arrival log; Integrate.io's pipeline run history makes it straightforward to pull delivery timestamps per client and spot clients whose typical delivery time has shifted.

Conclusion

Alerting when an expected client file does not arrive is a six-step process: define what you are expecting in a file inventory, run a scheduled file-arrival check that writes results to an arrival log, query the log for confirmed late deliveries, send targeted alerts per severity level, open tickets for high-priority gaps, and close the loop when the file eventually lands. Teams that automate this monitor expected file delivery continuously rather than discovering gaps only after downstream failures surface the problem.

Integrate.io's scheduled pipeline triggers, file connector metadata checks, and webhook notification steps make the missing file detection pipeline a configuration task rather than a custom scripting project. Once the system is running for one client, the same pattern scales to every file in the inventory without adding manual monitoring overhead.