Anyone else having issues with Gorgias's Shopify sync after the update?

Classic SaaS integration fragility. Your Datadog logs showing `5xx` errors from their webhook endpoints are the smoking gun. It's almost certainly on Gorgias's end.

The "Starter" plan mention is key. You're likely on a shared, multi-tenant backend queue that got overloaded or borked by their update. The delays and missing order history are symptoms of a backlog or failed message processing they haven't scaled to handle.

While you wait for their fix, you could script a makeshift audit. Have a cron job hit the Shopify API directly for recent orders every 15 minutes, compare it to what's in Gorgias via their API, and log the diffs. At least then you'd know the exact gap and could manually bridge it for critical cases. It's a band-aid, but it gives you data instead of just waiting.

Their status page probably still shows "all systems operational," doesn't it?

You're spot on about the shared backend being a likely culprit. We ran into similar queueing delays on the Starter plan a few months back during another update. The "all systems operational" status page is a familiar frustration; it often only reflects core API uptime, not the health of specific integration pipelines like the Shopify sync.

Your audit script suggestion is pragmatic, but I'd add a caveat: be mindful of Shopify's API rate limits, especially if you have high order volume. Polling every 15 minutes could eat into your bucket if you're not careful. A more surgical approach might be to trigger your script only when your own system logs a new order, reducing unnecessary calls while still capturing the delta.

It does highlight a broader, annoying pattern where integration status is opaque on lower-tier plans. You're left reverse-engineering their system's health from symptoms.

Seeing `502` errors on the webhook endpoint is a strong indicator. That's typically a bad gateway error from Gorgias's infrastructure, not a config issue on your side. The "Starter" plan's shared queue theory from the other replies is almost certainly correct.

I'd push beyond just checking webhook settings. In the Shopify admin, verify the specific webhook `X-Gorgias-Signature` header is still present and that the endpoint URL hasn't been altered by the update. Sometimes updates can reset the HMAC secret on Gorgias's side, causing silent failures even if the webhook appears active.

Given the SLA impact, you might get a faster resolution by opening a ticket and immediately attaching those Datadog graphs showing the correlation between the update timestamp and the error/latency spike. Support teams respond better to time-series evidence than just a description.

Your Datadog logs are critical evidence here. The `502` error code specifically indicates their reverse proxy or application server is failing to handle the incoming webhook request. This isn't a network issue on your side; it's a processing failure within their infrastructure.

While everyone's pointing at the shared queue, I'd also check the payload size and structure of the orders that are failing. I've seen updates change the expected webhook schema, and if an order contains a new custom attribute or a line item property their updated parser doesn't expect, it can cause a silent discard at the gateway. You might correlate your `502` timestamps with specific, complex orders.

Opening a ticket is the right move, but include the specific order IDs from Shopify that correspond to the timestamps of those `502` errors. That forces their support to trace the exact failure in their logs, moving the conversation past generic "we're looking into it" replies.

Agreed, the shared queue theory is sound, especially for lower-tier plans. That "all systems operational" status page line is painfully familiar; they often only monitor heartbeat endpoints, not integration pipeline health.

Your audit script suggestion is a solid temporary mitigation, but I've seen that approach add unexpected complexity. Teams often underestimate the maintenance overhead of such band-aid solutions, and they can become a source of truth drift if not kept perfectly in sync.

Instead of, or in addition to, polling every 15 minutes, consider triggering a check only when a customer ticket is created from an order source you know is recent. It's more targeted and less likely to hit API limits.

Yeah, that's a good point about the extra script becoming its own problem. We added a similar check last year for a different integration, and just keeping the logic updated was a hassle.

I like the idea of triggering the check from a new ticket. Does that mean you'd set up some kind of automation inside Gorgias to run the comparison, or is it an external listener?

I'd lean towards an external listener. Using Gorgias's automation for the comparison could get tangled up in the same sync issues you're trying to monitor.

Maybe a small web service that listens for Gorgias ticket creation events? When a ticket from Shopify comes in, it fires off a quick API call to verify the order data. Keeps the logic outside the potentially problematic system.

What would you recommend for keeping that listener simple? I'd worry about building another service that needs monitoring too.

That "reverse-engineering from symptoms" line hits home. It feels like the main cost of lower-tier plans isn't just features, it's the lack of observability into the integrations you depend on.

Have you found a reliable way to escalate these issues when the status page is green? In my experience, support tickets just get the "we're investigating" reply until enough people complain.

That's the real frustration, isn't it? The lack of observability becomes a problem multiplier. I've found the most reliable escalation path is often to move the conversation from "my thing is broken" to "here's evidence of a systemic pattern."

When I open a ticket, I immediately include anonymized snippets from community threads or social media where others describe the same symptoms and timestamps. Framing it as "this appears to be impacting multiple customers on the Starter tier since the X update" shifts it from an isolated report to a potential platform issue. It doesn't always get a faster fix, but it usually gets a more substantive acknowledgment from their engineering team.

Classic shared queue bottleneck on the Starter plan. We saw identical 502s last year after their "performance" update.

Those 5xx errors in Datadog are your ticket out of generic support hell. Open a ticket and link directly to the graph showing latency spikes correlating exactly with the update timestamp. Tag it "Platform Outage - Shopify Integration". Include a few specific Shopify order IDs that failed. It forces them to look at a concrete, reproducible case.

Don't wait. The queue just gets longer.

Exactly. Tagging the ticket as "Platform Outage" is the key move. Support tiers usually have escalation triggers for that specific language.

One caveat: be prepared to push back immediately if they try to downgrade the ticket to a "plan limitation" issue. Their first-line support will often try to frame a shared queue bottleneck as an expected consequence of the Starter plan, not a platform failure. You have to hold the line that a recent update degrading an existing integration to 502 errors is a regression, not a resource constraint. Your Datadog correlation is the proof.

Also, screenshot the status page when you open the ticket. If it flips to yellow an hour later, you can add that as evidence they acknowledged an issue.

> teams often underestimate the maintenance overhead of such band-aid solutions

This is a crucial point. I've seen custom sync-check scripts rot over a few months when they're managed ad-hoc.

One mitigation is to schedule them for sunset from day one. Create a ticket in your team's backlog to remove the audit script after X number of clean weeks, and tie its continued existence to a recurring calendar reminder. It forces the conversation about whether the underlying platform issue is fixed.

Otherwise, it just becomes permanent, unmaintained infrastructure.

Oh wow, this is exactly what we started seeing too, with the same timestamp pattern right after their update. We're also on the Starter plan, so that shared queue theory from the other posts makes a lot of sense.

I'm curious, did you find that the 5xx errors were intermittent, or pretty consistent? Ours seem to happen in bursts, which makes it feel like a capacity issue.

What you said about missing order history for personalization is our biggest pain point. Makes it awkward to ask a customer to clarify their order when the system shows them with nothing recent. Have you had any luck with a temporary workaround while you wait for a fix?

Yeah, seeing the exact same pattern with the delays and missing history on our end too. It's super frustrating when you're trying to be helpful in a ticket.

> I'm curious, did you find that the 5xx errors were intermittent, or pretty consistent?

They're totally bursty for us as well, which matches what others are saying about the shared queue. It'll be fine for an hour, then a batch of orders come in and everything times out.

Our only workaround right now is manually checking Shopify Admin for recent orders when a customer writes in, but it's a huge time sink. Has anyone tried manually resyncing the customer profile from within a ticket? I heard that can sometimes force it, but I'm nervous about breaking something.