Adobe ColdFusion and Lucee can log outgoing HTTP requests. BoxLang now provides the same useful production troubleshooting visibility: every outgoing request can log its URL, method, response status, and duration. There is no separate HTTP-request logging setting to learn or manage. This feature is built on BoxLang’s existing logging framework, so you control it with the standard logger settings you already use.
The request messages are debug-level and disabled by default, so normal applications do not fill their logs with request details. Enable the existing http logger at debug when you need to troubleshoot an integration.
This feature is currently available in BoxLang 1.17.0-snapshot builds.
Enable It
For a CommandBox server, add this to your .cfconfig.json:
{
"loggers": {
"http": {
"level": "debug"
}
}
}
You can also enable it with CFConfig using an environment variable:
box_server_loggers_http_level=debug
For a MiniServer, add this to your boxlang.json:
{
"logging": {
"loggers": {
"http": {
"level": "DEBUG",
"appender": "file",
"additive": false
}
}
}
}
By default, the HTTP logger writes to http.log. Set its appender to console in boxlang.json or your CFConfig settings if you prefer to see the messages in the console.
What You Will See
Each outgoing HTTP request produces two debug-level messages:
[2026-08-05T14:30:31,560] [XNIO-1 task-2] [DEBUG] [HTTP] Starting HTTP REQUEST 2b {URL='https://www.google.com', method='GET'}
[2026-08-05T14:30:31,619] [XNIO-1 task-2] [DEBUG] [HTTP] HTTP REQUEST 2b completed {Status Code=200 ,Time taken=58ms}
The start message includes the URL and HTTP method. The completion message includes the response status and elapsed time. The thread name is already included by BoxLang’s logging system.
The request ID, such as 2b, is an auto-incrementing hexadecimal value shared by both messages. This makes it easy to pair start and completion logs, even when many HTTP calls run at the same time.
Better Production Troubleshooting
Adobe ColdFusion and Lucee can log outgoing HTTP calls, but BoxLang keeps this detail opt-in and uses the same logger configuration you already use elsewhere. Turn it on only while diagnosing an integration, keep it in its own http.log, or redirect it to the console when that is more useful.
That means you get the request URL, method, status code, duration, thread name, and a matching request ID without adding custom logging around every http call.