Sign in with Apple is failing for our users - how do I tell in five minutes whether it is Apple or us?

Get the raw error body out of the token exchange and stop reasoning about your SDK's wrapper. Most auth libraries collapse several distinct failures into one generic "sign in failed" that tells you nothing.

Once you have the raw body, the question usually answers itself: a 503 or a timeout is theirs, an OAuth error object with a specific code is yours. Log the raw body permanently if you do not already, because you will want it the next time too and the next time will also be at a bad moment.

Shape test, in the order I would run it.

Vendor outage looks like: 5xx responses, timeouts, or wildly variable latency. Affects every flow including native. Starts for everyone within the same couple of minutes. Error bodies are inconsistent between attempts.

Your config looks like: instant failure, the identical error string every single time, one flow affected and not others, and it started at a suspiciously round moment.

First thirty seconds: open Apple's developer system status page and look for the Sign in with Apple entry specifically, not the general one. Next thirty: retry and check whether the error body is byte identical. Deterministic identical errors are almost never an outage.

Boring answer that resolves most of these: decode the client secret you have configured and read its exp.

Apple's client secret is a JWT with a maximum lifetime of about six months, and when it lapses the token exchange fails deterministically with no warning and no notice from Apple. Web and Android flows break while native sign in can keep working, which matches exactly what you described about iOS still being fine.

Do that before anything else. It is a ten second check and it is either your whole incident or it is ruled out.

Incident hygiene, since you said two person team and no ops: do not roll back a deploy that is not implicated. You have not deployed since Tuesday and this started today, so the deploy is not the cause and rolling it back only adds a variable.

Keep a running note of what you checked and when. Not for the postmortem, for you in forty minutes, when you cannot remember whether you already tested from the hotspot.

Plot failure rate by minute and by platform before you form an opinion. The shape tells you more than the errors do.

A vertical cliff at one timestamp, with one platform going to zero and others unaffected, is an expiry or a config change. A ragged ramp with partial success throughout, hitting everything, is an upstream incident. If you already have the data in a dashboard this takes a minute and it is the single most convincing artefact to put in front of whoever asks you what happened.