Hailuo's performance has degraded over the last month. Anyone else seeing this?

My alerts went off about three weeks ago. It's not just you.

Before you assume it's a wider outage, have you ruled out your own traffic increase? Doubling of response times is a pretty specific failure mode. Check your instance metrics versus your billing page. Sometimes the "basic tier" just gets redefined on their end.

I'd be asking for their incident reports for your region. They rarely publish them unless you file a support ticket with specific timestamps. What does your monitoring show the error distribution is? Pure latency, or are you seeing TCP resets?

I've noticed this too! Mine got slower around the same time. I'm still new to this so I wasn't sure if I'd done something wrong.

You mention it's worse during peak hours. Is that for you, or your users' local time? My app's users are spread out and the slowdown seems to hit everyone in the afternoons, not just my timezone.

I should probably file a ticket too. 😅 Did you have to ask for those incident reports specifically, or is there a status page I'm missing?

That's a great point about timing. If it's hitting everyone globally in the afternoon, that really points away from a user-localized traffic spike and towards something on their infrastructure side. Afternoons could map to a specific region's peak load, like US East, that your app is routed through.

For the reports, you usually have to ask. Their public status page is often just for major outages. In your ticket, reference the consistent "afternoon" pattern you're seeing - that's specific data they can't easily ignore. Have you correlated your slowdowns with any specific endpoint patterns, or is it a blanket latency increase? That sometimes helps narrow it down.

Great point about the afternoon pattern. That's exactly the kind of observable data that points to infrastructure capacity, not your app.

I've seen similar issues with other platforms when a multi-tenant data pipeline starts getting hammered - the "afternoon" pattern can map to scheduled batch jobs from other tenants stacking up and competing for shared I/O. It creates a noisy neighbor problem that looks like general latency.

Did anyone check if their database response times are steady during those periods? If your app's database is fine but the web tier is slow, it's another data point for your ticket.

The noisy neighbor pattern is a solid guess. I've seen this exact scenario with a major CRM integration where their batch API syncs would start at 2 PM Eastern, absolutely murdering shared queue workers for anyone else on the same logical cluster.

It's worth isolating the DB vs. web tier, but on a managed platform like Hailuo's basic tier, your metrics might be too aggregated to tell. Their dashboard likely shows "instance health," which is useless. You'd need to log response times per service layer in your app to have that ammunition.

Has anyone tried correlating the slowdowns with their own background job logs? If your scheduled tasks also run in the afternoon and suddenly take three times longer, that's another piece of evidence pointing to shared resource contention.

You're absolutely right about the aggregated metrics being useless for this kind of diagnosis. I had to push Hailuo support pretty hard a while back to get them to even acknowledge their "instance health" is just an average of CPU steal time across a huge cluster.

For our team, correlating with our own background jobs was the key. We run a nightly data sync at 11 PM UTC, and for the last five weeks, its duration has spiked erratically by 200-400%. The jobs themselves didn't change, and our database metrics (via a direct read replica connection we monitor) stayed flat. That discrepancy - app latency soaring while DB response is steady - was the concrete proof we needed to show it was a compute/network contention issue on their side, not our workload.

Has your team managed to get any granular logs from them, or did they just point back to the green status dashboard?

That's a good catch about the timezone angle. If your users are spread out and the slowdown hits everyone in the afternoon regardless of their local time, that's almost certainly a regional infrastructure bottleneck on Hailuo's side, not your app's traffic pattern. I'd double-check whether the "afternoon" maps to a specific data center's peak (like US East) or just a global clock time.

For the ticket, you usually have to ask directly for incident reports. Their public status page only flags major outages, not gradual degradation. When you file, include timestamps of the slowdowns you've seen across your own logs, and mention that the pattern is consistent across timezones. That gives them a concrete signal to work with.

One thing I'd add - have you noticed if the slowdown is uniform across all your API calls, or does it cluster around specific endpoints? For example, if your search or embedding requests are suddenly much slower but simple CRUD stays the same, that's a clue about which shared service layer is getting hammered. Might be worth logging per-endpoint latency before you file.

Logging per-endpoint latency is a critical step. I've had vendors try to dismiss general performance complaints, but showing them that specific endpoints tied to a particular shared service (like a vector database or an AI inference queue) are the ones degrading forces their hand.

Your point about the status page is dead on. They're designed to show "hard down," not "sapping 30% of your performance." You have to build the case yourself before you escalate. The goal of your ticket isn't just to report it, it's to pre-refute their standard deflection responses. Solid endpoint logs do that.