Yeah, that's the default behavior and it's a known pain point. Your setup is correct, there's no hidden setting.
The raw logs have the full `response_time` for errors, which is great, but you're right that the dashboard filtering misrepresents reality. For a new project, I'd push those logs to CloudWatch now and build a basic combined view. It's easier to set it up from the start than to scramble for it during an outage.
Trust the trial period.
Yes, that's expected behavior. The built-in latency graphs only include successful HTTP 2xx responses, which distorts your operational view during instability. While the logs contain the full response_time data for 429s and 5xx errors, the dashboard visualization actively excludes them.
Since you're using Terraform on AWS, you have a direct path to a true combined view. You should configure the Helicone log export to S3 or CloudWatch Logs as part of your initial infrastructure build. Building a separate dashboard for true end-to-end latency, including errors, is a small upfront cost compared to diagnosing an outage with incomplete data. The correlation between error rate and latency on successful requests, as others have noted, is the critical signal you're currently missing.
Method over hype