Production Readiness & Monitoring

Health check endpoint

health.cfm tests the DB on every request and returns 200/503 — used by load balancers and container probes.

Every production ColdFusion application should expose a /health.cfm endpoint that:

1. Tests the database connection
2. Returns JSON with a status field ("ok" or "degraded")
3. Returns HTTP 200 when healthy, 503 when degraded

<!--- health.cfm --->
<cfscript>
  status   = "ok";
  httpCode = 200;

  try {
    queryExecute("SELECT 1", {}, {datasource: "training_db"});
  } catch (any e) {
    status   = "degraded";
    httpCode = 503;
  }

  cfheader(statuscode=httpCode);
  cfheader(name="Content-Type", value="application/json");

  writeOutput(serializeJSON({
    "status":    status,
    "timestamp": dateTimeFormat(now(), "yyyy-mm-dd'T'HH:nn:ssXXX"),
    "version":   "1.0.0"
  }));
</cfscript>

Log aggregation

ColdFusion writes logs to /opt/coldfusion2025/cfusion/logs/. Tail the application log:

tail -f /opt/coldfusion2025/cfusion/logs/application.log

Key log files:

Monitoring from the command line

The Performance Monitoring Toolset (pmtagent) requires an external Elastic Stack and is not available in this lab. Instead, use these CLI commands directly in the Terminal tab:

Tail the live application log:

tail -f /opt/coldfusion2025/cfusion/logs/application.log

Check CF server memory (JVM heap):

ps -o pid,rss,vsz,comm -p $(pgrep -f "box server start")

Your lab VM output — ps fallback when jcmd native memory is unavailable.

Watch active CF threads:

watch -n 2 "ps -eLf | grep java | grep -v grep | wc -l"

Note: In this lab ColdFusion runs as a different system user, so watch can only see the process name (java) — not the full command line. Counting all java threads is fine here because ColdFusion/CommandBox is the only Java process running. A healthy idle server shows 100–150 threads.

# See which threads are consuming the most CPU right now
ps -eLo pid,lwp,pcpu,nlwp,comm | grep java | grep -v grep | sort -k3 -rn | head -10

Check datasource configuration:

# List registered datasources and their JDBC URLs (no JVM startup needed)
grep -E "<var name='NAME'>|<var name='url'>|<var name='CLASS'>" \
  /opt/coldfusion2025/cfusion/lib/neo-datasource.xml \
  | grep -o ">.*<" | tr -d '><'

Test live datasource connectivity:

# health.cfm already runs SELECT 1 — use it as your connectivity probe
curl -s http://localhost:8500/health.cfm

Note: box cfconfig datasourceList launches a second JVM and will be killed by the OS on this lab VM (only ~512 MB RAM). Read neo-datasource.xml directly instead — it is the source of truth CF reads at startup.

View recent exceptions:

tail -40 /opt/coldfusion2025/cfusion/logs/exception.log

# Count how many times each exception type appears — spot patterns instantly
grep "^\"" /opt/coldfusion2025/cfusion/logs/exception.log \
  | awk -F'"' '{print $2}' | sort | uniq -c | sort -rn | head -10

Why health.cfm matters beyond this lab

You just built health.cfm as a learning exercise — but this same pattern is used in real production systems every day. Here is why it exists.

The problem it solves:

When a load balancer sits in front of your ColdFusion server (which is standard in any production setup), it needs a way to know whether your server is actually able to handle requests right now — not just whether the process is running, but whether the application is healthy. The process can be running while the database is down, the connection pool is exhausted, or a deployment is half-finished. Without a health endpoint, the load balancer sends traffic to a broken server and users get errors.

How it is used:

Any monitoring system, load balancer, or deployment tool can call GET /health.cfm and make a decision based on the HTTP status code:

You do not need Docker or Kubernetes to use this. Even a simple cron job checking your endpoint every minute and sending you an email on failure is a health check. The endpoint you built is the standard way to expose application health — the consumer of that endpoint (load balancer, cron, monitoring tool, container orchestrator) is a separate concern.

ColdFusion in real deployment environments

How companies actually deploy ColdFusion varies widely. There is no single standard, but a few patterns are common:

The typical 3-stage pipeline:

Code moves left to right — only promoted after review or tests pass at each stage.

The Lucee-on-dev, Adobe-on-prod reality:

Dev and Test/QA run Lucee to keep costs down — Production runs Adobe ColdFusion under a commercial license.

Many ColdFusion teams run Lucee (free, open source) on dev and test environments to keep costs down, and only pay for Adobe ColdFusion licenses on production. This works because CFML is largely compatible between the two engines — but there are differences, especially around:

• ORM / Hibernate behaviour
• Some tag attributes and default values
• Java library versions bundled with each engine
• cfchart, cfdocument, and other Adobe-specific packages

The safest approach is to run your test environment on the same engine and version as production. If that is not possible, test on Lucee but always verify on Adobe CF before deploying.

On uptime and availability:

Adobe ColdFusion comes in two deployment models:

For self-hosted deployments (the most common setup), uptime is the responsibility of whoever runs the infrastructure. Major cloud providers publish a 99.99% SLA for their virtual machines — roughly 52 minutes of downtime per year. Reaching that requires redundancy: multiple CF instances behind a load balancer, automated health checks, and automated restarts on failure.

For Adobe ColdFusion for Cloud, Adobe manages the infrastructure and publishes their own SLA — check the Adobe ColdFusion for Cloud documentation for the current terms, as these change over time.

Either way, health.cfm is your application's contribution to that uptime number — it is the signal that tells the infrastructure whether CF is ready to serve traffic.

Your health.cfm fits into this pipeline at every stage. Each environment should have its own health endpoint — same code, different datasource URLs — so your monitoring and deployment tools can probe any stage the same way.

Activity 1 — Create the health check endpoint

What you are building: /opt/coldfusion2025/cfusion/wwwroot/health.cfm — a JSON endpoint that tests the database connection and returns the correct HTTP status code.

In the Terminal tab, run:

sudo tee /opt/coldfusion2025/cfusion/wwwroot/health.cfm << 'EOF'
<cfscript>
  status   = "ok";
  httpCode = 200;

  try {
    queryExecute("SELECT 1", {}, {datasource: "training_db"});
  } catch (any e) {
    status   = "degraded";
    httpCode = 503;
  }

  cfheader(statuscode=httpCode);
  cfheader(name="Content-Type", value="application/json");

  writeOutput(serializeJSON({
    "status":    status,
    "timestamp": dateTimeFormat(now(), "yyyy-mm-dd'T'HH:nn:ssXXX"),
    "version":   "1.0.0"
  }));
</cfscript>
EOF

Verify it returns valid JSON:

curl -s -w "\nHTTP: %{http_code}\n" http://localhost:8500/health.cfm

Activity 2 — Confirm the status field

The response JSON must contain a status field set to "ok" (DB reachable) or "degraded" (DB unreachable).

curl -s http://localhost:8500/health.cfm \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['status'])"

Activity 3 — Confirm the HTTP status code

A healthy endpoint must return HTTP 200. If the DB is unreachable it must return HTTP 503. Any other code means the endpoint is not production-ready.

curl -s -o /dev/null -w "HTTP %{http_code}\n" http://localhost:8500/health.cfm

When all the checks above are green, this lesson is complete — and so is the course. 🎉