I love debugging, it is a fun process of trying to grab a trace of evidence by finding patterns and using good searching algorithms. But debugging is not magic, we need data to get to the bottom of problems.
As a customer support engineer, I spend most of my time trying to get the right information and clarifying details when I receive new tickets. Tickets that contain the information listed below are resolved much more quickly. Including these pieces of information also gives us a better understanding of your application and the actual issue. I gathered a minimum list of information we need to start debugging. Hope it helps!
Sending us any keys or tokens would be a very bad move, please remove them from your message.
Summary of what the issue is and timing, when it started and finished.For example, revalidation header sending from origin is not working even though the contents have not been updated.
Expected outcome and Actual result
What is an expected outcome and what do you see instead? For example, when sending a request to example.com/index.html, I would expect 304 as the content has not been modified but receive 200 instead.
What are the steps to reproduce the issue? We need at least a full url including host name. Information of the way to send the request such as on browser or by cURL would be very helpful, too. If you observe an issue on the Fastly UI, tell us know the page url you are trying to access.
Did you see it or did some of your customers report the issue? If you know how many clients have been affected by this issue, (such as 10% of your customers or 3 reports from the US), it would help us pinpoint where we should search the issues and to assess the urgency.
Logs and screenshot as well as any debug or testing you have done so far.
If it is not on a specific URL and happening on the account level or service level, please provide the Customer ID (Account ID) or Service ID.
Please sign in to leave a comment.