Troubleshooting

When a FastEdge application fails, the response includes a FastEdge-specific 5xx status code. The code identifies whether the failure happened during initialization, execution, timeout, or memory allocation.

Start by identifying the returned status code. Then enable debug logging to capture application output and investigate the root cause.

HTTP error codes

Code	Meaning	Common causes
530	Application initialization failed	Missing or invalid environment variable, wrong compilation target, corrupt binary
531	Runtime error — unhandled exception	Rust panic, JavaScript TypeError, failed outbound request, unexpected null
532	Execution timed out	Handler exceeded the execution time limit; check for infinite loops, expensive processing, or slow outbound calls
533	Memory limit exceeded	Application allocated more memory than the plan allows

Debug logging

Production applications do not write logs by default. Enable debug mode before reproducing the issue to capture console.log output (JavaScript) or println! output (Rust).

Enable debug mode:

curl -X PATCH "https://api.gcore.com/fastedge/v1/apps/{app_id}" \
  -H "Authorization: APIKey $GCORE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"debug": true}'

Debug mode stays active for 30 minutes and then turns off automatically. Reproduce the failure, then retrieve the logs:

curl "https://api.gcore.com/fastedge/v1/apps/{app_id}/logs" \
  -H "Authorization: APIKey $GCORE_API_KEY"

Available query parameters: from, to, edge (specific PoP), client_ip, request_id, search.

Platform limits

Exceeding the limits below triggers a 532 (timeout) or 533 (memory) response. Check which plan your application is on if you see these codes repeatedly.

Resource	Basic	Pro
Execution time	50 ms	200 ms
Memory	128 MB	256 MB
Outbound requests	5 per invocation	20 per invocation
Request / response body	1 MB	5 MB
Binary size	~50 MB	~50 MB

Common application issues

Request headers missing at the origin

If a CDN application adds or sets a request header and the origin never receives it, check the header name. Headers with the x-cdn- or x-gcdn- prefixes are reserved for internal CDN use and are stripped before the request reaches the origin. Use a different prefix, such as x-fastedge or an application-specific name. The Proxy-Wasm header APIs do not return an error for reserved names.

Rust: log output not appearing

eprintln! writes to stderr, which FastEdge does not capture. Use println! for any output that should appear in debug logs.

JavaScript: unavailable APIs

The following are not available inside FastEdge JavaScript applications:

• Node.js built-ins: node:crypto, node:fs, node:buffer, process, require
• WebSocket
• Web Cache API — use the Cache module (import { Cache } from 'fastedge::cache') instead

Local testing

Before deploying, test the application locally with fastedge-run, a local HTTP server for compiled Wasm binaries:

fastedge-run http -w ./app.wasm --port 8080

Full fastedge-run usage is in FastEdge CLI. Three more tools speed up local development: Test framework for headless test suites and a browser debugger, the FastEdge extension for building and debugging inside VS Code, and AI-assisted development for scaffolding and deploying apps through Claude Code, Codex, or Cursor.

Related resources

Resource	Link
Rust SDK examples	github.com/G-Core/FastEdge-sdk-rust/examples
JavaScript SDK examples	github.com/G-Core/FastEdge-sdk-js/examples
AssemblyScript SDK examples	github.com/G-Core/proxy-wasm-sdk-as/examples
Rust SDK	github.com/G-Core/FastEdge-sdk-rust
Rust API reference	docs.rs/fastedge
JavaScript SDK	github.com/G-Core/FastEdge-sdk-js
JavaScript reference	g-core.github.io/FastEdge-sdk-js
AssemblyScript SDK (CDN apps)	github.com/G-Core/proxy-wasm-sdk-as