Overview of the Problem
A ColdFusion scheduled task “not running” means one or more tasks you configured in the ColdFusion Administrator fail to fire at their scheduled times, never execute, or execute but don’t complete as expected. This issue can manifest as missed runs, repeated misfires, empty or stale “Last Run” timestamps, or errors like 403/404/500/PKIX failures in task results. The root causes range from disabled scheduler services to network, SSL, Authentication, timeout, permission, code-level, and clustering problems.
Why it happens:
- ColdFusion uses an internal scheduler (Quartz under the hood) that triggers HTTP requests or file publish actions. Any break in the chain—service, Configuration, code, network, Authentication, filesystem, JVM—can prevent a run or cause it to fail silently.
- Misconfiguration (dates, concurrency, timeouts, proxies), environmental constraints (IIS/Apache bindings, DNS, certificates), or bugs (outdated CF/Java) are common.
Possible Causes
Platform and Service-Level
- ColdFusion service not running or restarting unexpectedly
- Scheduler feature disabled in Administrator
- JVM memory pressure causing stalls or long GC pauses
- OS-level firewall or corporate proxy blocking outbound requests
Task Configuration
- Task is disabled/paused or has a start date in the future/end date in the past
- Misfire settings and concurrency conflicts (previous run still executing)
- Request timeout too low for the job length
- URL/endpoint incorrect, requires authentication, or blocked (403/401)
- HTTPS certificate/truststore issues causing SSL handshake failure
- Using localhost/host header/binding mismatch in IIS/Apache
Application/Code-Level
- Page requires login or CSRF token not supplied by the task
- Long-running queries, deadlocks, or errors unhandled by code
- File/FTP publish path permissions (UNC paths, service account rights)
- Scheduled output failing due to disk permissions or Path errors
Infrastructure and Clustering
- DNS resolution problems on the server
- Connector misconfiguration (mod_jk/isapi) or WAF rules blocking requests
- Multi-instance or clustered setup with tasks configured on wrong instance or running on multiple nodes unexpectedly
- neo-cron.xml corruption or outdated ColdFusion/Java with known scheduler bugs
Quick Cause/Solution Reference
-
Cause: Scheduler disabled in CF Admin
- Solution: Enable Scheduler in Server settings > Settings, then restart CF if needed.
-
Cause: Task disabled or invalid schedule (start/end date/time)
- Solution: Enable task, correct dates, verify timezone, and save.
-
Cause: URL requires login, token, or headers
- Solution: Add credentials in task or call a dedicated endpoint that bypasses login. Verify with curl.
-
Cause: HTTPS “PKIX path building failed”
- Solution: Import the site’s certificate chain into the CF/Java truststore via Administrator or keytool.
-
Cause: IIS/Apache host binding mismatch (localhost vs domain)
- Solution: Use the exact site hostname in the task URL; ensure DNS resolves on the server. Avoid relying on localhost if site binding requires hostname.
-
Cause: Request timeout too low
- Solution: Increase task timeout and/or use cfsetting requesttimeout in the target page.
-
Cause: Previous run still executing (no overlap allowed)
- Solution: Extend schedule interval, optimize code, or allow concurrent runs if safe.
-
Cause: Service account lacks permissions to paths or shares
- Solution: Run ColdFusion service under a domain/service account with required rights; use UNC paths.
-
Cause: Proxy/firewall blocks egress traffic
- Solution: Configure system proxy in CF Admin or bypass for internal addresses; coordinate with network team.
-
Cause: neo-cron.xml corrupted
- Solution: Backup, repair, or recreate tasks; update ColdFusion to latest update.
Step-by-Step Troubleshooting Guide
1) Verify Platform Health
- Confirm the ColdFusion service is running.
- Windows: Services > ColdFusion 2018/2021 Application Server (or instance name).
- Linux: systemctl status coldfusion or specific instance.
- Check logs for errors surrounding task times:
- CF logs: {cf_home}/cfusion/logs/ (coldfusion-out.log, coldfusion-error.log, scheduler.log if present)
- Web Server logs: IIS/Apache access/error logs
- Ensure Scheduler is enabled in ColdFusion Administrator:
- Server settings > Settings > Ensure “Scheduler” is checked.
- Check JVM memory usage and GC pauses:
- coldfusion-out.log for Full GC, long pauses; consider increasing Xms/Xmx or tuning GC.
2) Inspect the Task in ColdFusion Administrator
- Open Scheduled tasks; confirm:
- The task is Enabled (not paused or disabled).
- Start/End dates are valid. Ensure the end date has not elapsed.
- Repeat interval and time units are correct.
- Timezone is as expected; consider DST impacts.
- Publish and Save Output destinations point to valid paths the service account can write to.
- Review “Last Run,” “Next Run,” and any “Last Result” error message. If available, click “Run” to execute manually and observe.
3) Validate the Target URL
-
Use curl from the server to test the exact URL the task calls:
curl -I https://yourdomain.example.com/app/schedulerEntry.cfm
- Expect 200/204/302 depending on your design. If you see 401/403/404/500, fix the endpoint or authentication.
-
If the site is bound to a specific hostname in IIS/Apache, ensure the URL uses that hostname—not localhost.
-
If using HTTPS and you get an SSL error:
- Test with curl -v to see certificate chain details.
- Import the certificate into CF’s truststore (see commands below).
4) Check Authentication and Tokens
- If the page requires login:
- Use the “Username/Password” fields in the task if Basic/NTLM is acceptable.
- Prefer a dedicated scheduler endpoint protected by a secret token or IP allowlist.
- Consider bypassing CSRF on this endpoint by code or including the token in the URL or headers (if your stack permits).
- Confirm no SSO redirect loop occurs (e.g., 302 to login page each time).
5) Confirm Timeouts, Concurrency, and Misfire Behavior
-
Verify the Request Timeout setting for the task is sufficient.
-
In the target page, add:
to give up to 10 minutes if your logic requires it.
-
If runs overlap and you don’t permit concurrency, a job can be “stuck running.” Either:
- Shorten the job, increase interval, or
- Allow concurrency if your task is idempotent and thread-safe.
6) Check Filesystem/Publish Permissions
- If “Save output” or “Publish” is used:
- Use UNC paths (\server\share\path) not mapped drives.
- Ensure the ColdFusion service account has read/write permissions.
- If on Windows domain shares, run the service under a domain account with share and NTFS rights.
7) Review Application Code for Hidden Failures
-
Add logging at start and end of your task page:
…
-
Wrap long operations in try/catch; log exceptions:
-
Check for deadlocks (database locks), remote service timeouts, or mail server hangs that can kill or prolong requests.
8) SSL/TLS Trust and Certificates
-
If you see “PKIX path building failed” in logs, import the certificate:
9) Networking, Proxies, and DNS
- If your environment uses a corporate proxy for outbound HTTP/S:
- Configure proxy in CF Admin (System/Java & JVM or Server Settings > Proxy).
- Or bypass proxy for internal hosts.
- Validate DNS resolution:
- From server: nslookup yourdomain.example.com
- Consider a hosts file entry if internal-only.
- Check firewall/WAF that may block automated traffic; whitelist the CF server IP where necessary.
10) Clustering and Multi-Instance Considerations
- In Enterprise or multi-instance setups:
- Ensure the task is created on the intended instance (each instance has its own scheduler).
- If using cluster-aware tasks, configure to run on one node only or “run on all nodes” as your design requires.
- Avoid duplicate runs across nodes unless explicitly desired.
11) neo-cron.xml and Version Updates
- If tasks disappear or won’t execute after updates/restarts:
- Inspect cfusion/lib/neo-cron.xml for corruption.
- Backup, validate XML, and re-create tasks if needed.
- Apply the latest ColdFusion updates and ensure a supported Java version; some scheduler and DST-related bugs are resolved in updates.
Common mistakes and How to Avoid Them
- Using http://localhost when IIS/Apache site is bound to a hostname: use the actual domain.
- Relying on mapped drives (X:): services can’t see them; use UNC paths with proper credentials.
- Forgetting that the end date already passed.
- Assuming the global “Request Timeout” covers a long-running task: set per-task timeout or cfsetting.
- Not accounting for DST changes that shift run times; use UTC where feasible.
- Ignoring SSL trust on internal certificates; import certs into CF’s truststore.
- Leaving the task to call an endpoint that enforces SSO/CSRF; provide a scheduler-specific endpoint.
- Not monitoring logs; failures go unnoticed until business impact occurs.
Prevention Tips / Best practices
- Keep ColdFusion and Java fully patched; subscribe to Adobe security bulletins.
- Implement health checks: a task that logs a heartbeat, and/or monitoring to alert if a task hasn’t updated a “last_run_at” timestamp in the database.
- Make tasks idempotent, support retry, and handle partial failures gracefully.
- Use cfsetting requesttimeout and robust try/catch with logging and optional cfmail notification.
- For HTTPS, standardize on certificates that are trusted by Java; maintain an internal PKI process.
- For production, run CF service under a least-privilege service account with explicit permissions to required paths and shares.
- Document task settings; consider using the Administrator API to export/import tasks and store them in Version control.
- In clustered environments, design explicitly for single-node or all-node execution and document who owns the task.
- Prefer using fully qualified domain names (FQDN) and ensure DNS is consistent across environments.
- Regularly test “Run” from Admin and via curl; validate expected outputs.
Logs, Commands, and Configuration Examples
Sample ColdFusion Logs to Check
- {cf_home}/cfusion/logs/scheduler.log (if present)
- {cf_home}/cfusion/logs/coldfusion-out.log
- {cf_home}/cfusion/logs/coldfusion-error.log
Example error you might see:
ERROR coldfusion.monitor.scheduler – Error invoking scheduled task:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException:
PKIX path building failed: unable to find valid certification path to requested target
Increase Request Timeout in the Task Page
Minimal Logging Wrapper
curl Tests
-
Basic reachability:
-
With Basic Auth:
curl -I -u schedulerUser:TopSecret https://yourdomain.example.com/jobs/reindex.cfm
-
Verbose SSL Debugging:
Import Certificate to Truststore (alternative to Admin UI)
keytool -import -alias internal-example \
-file /tmp/internal-example.crt \
-keystore /opt/coldfusion/jre/lib/security/cacerts \
-storepass changeit
Example: Allowlist Scheduler by IP in Application.cfc
component {
this.name = “MyApp”;
function onRequestStart(targetPage) {
var schedulerIPs = “127.0.0.1,10.1.2.3”;
if (findNoCase(cgi.remote_addr, schedulerIPs) EQ 0 AND findNoCase(cgi.http_user_agent, “CF-Scheduler”) EQ 0) {
// enforce login or reject
}
}
}
Key Takeaways or Summary Points
- Start simple: ensure the ColdFusion service and Scheduler are enabled and healthy.
- Validate the task configuration (enabled, dates, interval, timeout, concurrency).
- Test the URL outside of ColdFusion (curl) and fix authentication, DNS, or SSL issues.
- Confirm filesystem and service account permissions for publish/save output operations.
- Add logging and Error handling to the task endpoint to expose silent failures.
- In clustered/multi-instance setups, verify the intended node(s) and avoid duplicate or missing runs.
- Keep ColdFusion and Java fully updated and address truststore, proxy, and DST nuances proactively.
FAQ
Why does my ColdFusion scheduled task show “Ran” but nothing happened?
- The URL may have returned 200 but the code inside did nothing due to Business logic, permissions, or feature flags. Add explicit logging at start/end, verify database changes, and check for swallowed exceptions in try/catch.
How can I stop a long-running or stuck scheduled task?
- If it’s a web request, it will end when the request timeout is reached. You can temporarily disable the task, restart the CF instance to free threads, or kill the underlying process if it’s invoking cfexecute. Then optimize the task and adjust request timeouts.
Should I call localhost or the public domain from a task?
- Prefer the exact hostname bound in IIS/Apache. Using localhost can hit the wrong site if bindings require a specific host header. If you must avoid the web server layer, consider hitting the Tomcat AJP/HTTP connector only if you know what you’re doing; otherwise use the FQDN.
What’s the best way to handle authentication for Scheduled tasks?
- Create a dedicated endpoint secured by a secret token or IP allowlist instead of regular user login. For Basic/NTLM, set credentials in the task. For OAuth/JWT, use a stable service account and refresh tokens programmatically.
Can I run the same task on all nodes in a cluster?
- Yes, but only if the operation is idempotent and designed for parallel execution. Otherwise configure the task to run on a single node (or use a leader-election approach) to avoid duplicate work or data corruption.
