The logs are great for identifying errors and the volume. But without seeing the full payload, seeing that a response code of 400 occurred is telling us only half of the problem.
I’m happy to be directed to somewhere that this is viewable.
I also pre-empt the “You should handle the response code and reporting better on your side” response. However, many of us may be the Ops people and not the development / engineering team, and often need proof that there is a problem to be investigated
Hey Ross,
Can you please give more details about your problem?
Any tags developed by Stape have a logging option:
You can enable this (Always log to console) and you will have request and response logs available for events with these tags.
If you have a problem on an incoming request (access logs) the response 400 is the standard sGTM response which means that your request has not been processed by any of the clients. That is, your request is not formed correctly or you do not have a client that handles this request.
It is the last paragraph I was trying to find a solution for.
I could see the 400 response, but I could not see what the request was. I knew what my development team was telling me the payload was, but I wanted to be able to look in the logs and validate that.
As I say, maybe I am in a niche situation, however I often need to validate what an engineering team tell me vs what is actually happening. And it seemed like if Stape was logging that a request was malformed, maybe an “easy” (I know, people always assume this) addition to the logs would be that we could view what the request and payload actually was.
Hi @Ross_Hopkins,
This would require sensitive information to be saved in the logs, which Stape does not do by default. But you can easily do this and log all incoming request data using the Logger tag: Tag Manager Template Gallery
These logs will be in the ‘Other’ tab and they will be linked to the access log on which the tag is triggered.
