A courts clerk office's document-classification endpoint is provisioned for business-hours peak load but sits mostly idle overnight, and the team wants to see this pattern clearly before deciding what to change. What should they do first?

Before changing an endpoint's provisioning, confirming the pattern with real metrics avoids acting on an assumption that might not hold — a performance and cost dashboard built from the endpoint's utilization data (invocation counts, instance utilization, and associated cost over time) makes the business-hours-peak, overnight-idle pattern visible and quantifiable, which is the evidence base for any subsequent decision like scheduled scaling or a lower overnight floor. Shutting the endpoint down overnight without first confirming the pattern risks cutting capacity that's still needed for some off-hours traffic the team hasn't accounted for, and skips the verification step entirely. Raising the minimum instance count moves in the opposite direction of the team's stated cost goal — it locks in the same idle capacity overnight instead of addressing it. Deleting historical metrics removes exactly the evidence needed to justify and later validate a change, leaving the team unable to confirm the pattern held or that a fix worked. Scope note: a single day's dashboard view can be misleading if traffic varies by day of week — review a representative window before deciding. Operational check: after implementing any change, re-check the same dashboard over a comparable period to confirm overnight utilization and cost actually moved.