Introduction
This article explains why data transforms may run out of schedule and how to troubleshoot the most common causes. If your transform is starting late, finishing late, or missing its expected run window, the steps below can help you identify the issue and get back on track.
Issue description
A transform is considered out of schedule when it does not trigger within its expected time window. This can happen occasionally during periods of high load, or repeatedly because of configuration, dependency, or infrastructure problems.
Signs
- The transform starts later than expected
- The transform triggers at a time of no scheduled trigger
- Runs are skipped, delayed, or queued
- Transform logs show retries, timeouts, or resource warnings
- Downstream reports are refreshed late
Common causes
Resource contention
Transforms can run late when compute, memory, or database resources are shared with other workloads. Heavy ingestion, concurrent queries or multiple transforms running at the same time can slow processing.
Upstream dependency delays
If a transform depends on source data, another transform or an external pipeline - any delay upstream can push the schedule back. Late-arriving data can also cause the transform to wait before it starts.
Long-running queries
Complex joins, large scans, inefficient filter or missing indexes can make queries run longer than the available schedule window. As data volumes grow, a query that used to complete on time may begin to overrun.
Scheduling conflicts
Two or more jobs scheduled at the same time may compete for the same resources. Conflicts can also occur when a transform is configured to run too frequently for the amount of work it needs to complete.
Infrastructure issues
Network interruptions, service degradation, node failures, or platform maintenance can delay execution. Intermittent infrastructure problems often appear as inconsistent timing rather than a complete failure.
Configuration errors
Incorrect schedule settings, timezone mismatches or misconfigured dependencies can cause a transform to run at the wrong time or not at all.
Basic troubleshooting steps
Use the following checklist to narrow down the cause of the delay.
- Confirm the transform schedule and timezone settings
- Check whether upstream jobs completed on time
- Review recent transform run history for retries, failures or long durations
- Look for overlapping jobs or other workloads using the same resources
- Inspect logs for timeout messages, throttling or connection errors
- Verify that any required source tables, views or dependencies are available
Advanced troubleshooting steps
Step 1: Review execution timing
Compare the scheduled start time, actual start time and completion time for recent runs. This helps you determine whether the issue is a delayed start, a slow execution or both.
Step 2: Identify bottlenecks
Check query performance, resource usage and queue times. If available, review query plans, execution metrics and platform monitoring data to find the slowest part of the process.
Step 3: Validate dependencies
Confirm that upstream data sources and dependent transforms finish before the scheduled run begins. If a dependency is consistently late, adjust the schedule or address the upstream delay first.
Step 4: Check for conflicts and capacity limits
Review concurrent jobs, capacity settings and any resource limits that may be causing queueing. If necessary, reschedule less urgent jobs to reduce contention.
Step 5: Confirm configuration
Verify schedule clashes, recurrence rules, timezone selection and any dependency triggers. Correct any mismatches between the intended schedule and the configured schedule.
Best practices for keeping transforms on schedule
- Stagger heavy transforms so they do not compete for the same resources
- Keep schedules aligned with upstream data availability
- Optimise queries and reduce unnecessary processing where possible
- Monitor run duration trends so you can spot regressions early
- Leave enough buffer time between dependent jobs
- Review schedule settings after changes to source data volume, logic, or infrastructure
Next steps
If the transform is still running out of schedule after you have checked the items above, collect the relevant run IDs, timestamps, logs, and configuration details before contacting support. Include any recent changes to schedules, dependencies, or infrastructure so the issue can be investigated faster.
Disclaimer
This article provides general troubleshooting guidance for Kleene data transforms. Your environment, configuration, and infrastructure may require different steps. Use your judgement when making changes, and involve your internal data or platform team if needed.