I've been evaluating OpenClaw for the last few weeks as a potential orchestration layer for our manufacturing and B2B e-commerce integrations, specifically for syncing NetSuite inventory and order data with our warehouse management system. One of the immediate hurdles I ran into, which I suspect others have as well, is the lack of detailed execution logs in their web interface. The dashboard shows basic success/failure status and high-level timing, but when a complex workflow with multiple steps fails, the default view gives you almost nothing to debug with—just a red "Failed" label.
After digging through their documentation and community forums (which are sparse), I discovered that OpenClaw, by design, treats detailed execution logs as a performance optimization and only surfaces them via their API under a specific query parameter. They aren't hidden per se, but they are certainly not promoted. To get the full step-by-step trace, including variable states at each juncture, transformation outputs, and the exact error payload from a failed HTTP request to our ERP, you must append `?detail=full` to the execution log endpoint.
So, instead of calling `GET /api/v1/executions/{id}/logs`, you need to call `GET /api/v1/executions/{id}/logs?detail=full`. The difference in the response payload is substantial. The default log might return a single line: "Step 'Transform Inventory Payload' failed." The full detail log will show you the input object, the exact JavaScript transformation code that was run, the state of the variables when it crashed, and the stack trace. This was crucial for me to pinpoint that a null value from a NetSuite item field query was not being handled in our custom mapper.
I've set up a monitoring script that now polls for failed executions and immediately fetches these detailed logs, parsing them into a shared error-tracking system. This has cut our diagnosis time for integration faults from sometimes an hour down to a few minutes. The lesson I took from this is that with modern SaaS platforms, especially in the integration and workflow automation space, the most critical debugging information often exists behind API flags that aren't immediately obvious. It's worth meticulously reading the API reference section of any documentation, not just the user guides, as the operational transparency you need might be a single query parameter away.
That's a familiar pain point with many orchestration tools. The `?detail=full` parameter pattern reminds me of how some early Jenkins pipeline APIs required `?depth=2` to get nested stage logs.
Have you considered automating the retrieval of these full logs on failure? You could hook a notification step that, upon a failed execution, immediately calls that detailed endpoint and parses the error payload into your incident management system. It saves a manual step during an outage.
Commit early, deploy often, but always rollback-ready.
Good catch on the automation idea! That's exactly how we handle it. Our monitoring stack triggers a Lambda function on any OpenClaw failure status from CloudWatch, which fetches the full logs and posts them to a dedicated Slack channel.
One caveat: watch your API rate limits if you have a spike in failures. We got throttled once during a cascading issue and missed the crucial first error. We added a simple queue (SQS) as a buffer, which fixed it.
It saves our team tons of time - no more manually fetching logs during a fire drill.
Right-size everything
Ah, the old hidden detail parameter trick. It's frustrating when platforms do that - makes you wonder if it's for performance or just to keep their UI looking clean.
You mentioned getting variable states at each step, which is huge for debugging. I've found that sometimes even `detail=full` doesn't include the *request headers* sent to external APIs, which can be crucial for auth issues. You might need to check if OpenClaw has a separate audit trail feature for that.
If you're working with Python, here's a quick snippet I use to wrap those API calls and always pull detailed logs:
```python
def get_execution_logs(execution_id):
response = requests.get(
f"{BASE_URL}/api/v1/executions/{execution_id}/logs?detail=full",
headers={"Authorization": f"Bearer {API_KEY}"}
)
# Always parse the 'transformation_outputs' key - it's usually where the good stuff hides
return response.json().get('transformation_outputs', [])
```
Did you run into any rate limiting when polling for those detailed logs?
Clean code, happy life