What causes "Logging disabled for backend bindings" in Budibase/budibase?

Use processStringSync (no logs) in backend/server contexts.

Logging disabled for backend bindings

Error message

Logging disabled for backend bindings

What it means

processStringWithLogsSync in packages/string-templates/src/index.ts returns binding logs alongside the rendered result. Logging is only supported in frontend/browser contexts; when isBackendService() is true (server/worker environments) it throws "Logging disabled for backend bindings" because backend template processing deliberately does not collect or emit logs.

Source

Thrown at packages/string-templates/src/index.ts:505

        })
        .map(value => JSON.stringify(value))
        .join(" ")
    } catch {
      throw new Error("Multi-object JSON templates must be valid JSON objects")
    }
  }
}

/**
 * Same as function above, but allows logging to be returned - this is only for JS bindings.
 */
export function processStringWithLogsSync(
  string: string,
  context?: object,
  opts?: ProcessOptions
): { result: string; logs: Log[] } {
  if (isBackendService()) {
    throw new Error("Logging disabled for backend bindings")
  }
  return processStringSyncInternal(string, context, {
    ...opts,
    logging: true,
  })
}

/**
 * By default with expressions like {{ name }} handlebars will escape various
 * characters, which can be problematic. To fix this we use the syntax {{{ name }}},
 * this function will find any double braces and switch to triple.
 * @param string the string to have double HBS statements converted to triple.
 */
const escapeRegExp = (value: string) =>
  value.replace(/[.*+?^${}()|[\]\\]/g, "\\$&")

export function disableEscaping(string: string) {
  const matches = findDoubleHbsInstances(string)

View on GitHub (pinned to a81a902e9a)

Solutions

Use processStringSync (no logs) in backend/server contexts.
Move the logging call to frontend code where binding logs are supported.
Gate the call: only use the WithLogs variant when not running as a backend service.
If you need visibility server-side, log inputs/outputs around processStringSync yourself.

Example fix

// before
const { result, logs } = processStringWithLogsSync(template, ctx) // in server code
// after
const result = processStringSync(template, ctx)

Defensive patterns

Strategy: try-catch

Validate before calling

import { isBackendService } from "@budibase/string-templates"
// only call the WithLogs variant in non-backend contexts
const useLogsVariant = !isBackendService()

Try / catch

let result: string
let logs: Log[] = []
try {
  const out = processStringWithLogsSync(template, ctx)
  result = out.result
  logs = out.logs
} catch (e) {
  if (e.message === "Logging disabled for backend bindings") {
    result = processStringSync(template, ctx)
  } else throw e
}

Prevention

Use processStringWithLogsSync only in frontend/browser code
Default to processStringSync in shared/server code paths
Gate logging variants behind an isBackendService() check at the call site
If server-side visibility is needed, wrap processStringSync with your own logging

When it happens

Trigger: Calling processStringWithLogsSync (instead of processStringSync) from server-side code — e.g. automations, queries, or API steps running in the server/worker where the backend-service flag is active.

Common situations: Debugging automation bindings by switching to the *WithLogs variant in server code; shared code paths that use the logs variant unconditionally; tests simulating backend rendering with the logging API.

Related errors

AI-assisted analysis of Budibase/budibase@a81a902e9a (2026-08-29). Data as JSON: /api/errors/8ac52eb799bb1648. Report an issue: GitHub.