Fix Google Chat Webhook 401 Unauthorized (UNAUTHENTICATED) for Developers: Key/Token vs OAuth Troubleshooting

A Google Chat webhook 401 Unauthorized (UNAUTHENTICATED) almost always means one thing: your request is reaching an endpoint that expects a different kind of authentication than you’re providing, or it’s receiving credentials that are missing, malformed, or no longer valid.

Most “401” cases come down to a fast fork in the road: incoming webhook key+token (simple notification posting) versus Google Chat API OAuth (scoped API access). Once you identify which lane you’re actually in, the fixes become mechanical and repeatable.

If Google Chat is calling your service (Chat app events), a 401 can also be your server rejecting Google because request verification (bearer token validation) or platform permissions aren’t configured correctly, so the “auth failure” is on your side.

Introduce a new idea: the quickest way to stop wasting time is to treat 401 debugging as a decision tree—first identify “who is rejecting whom,” then confirm the auth model, then verify URL integrity, then validate request shape.

Is a 401 “Unauthorized / UNAUTHENTICATED” always an authentication problem?

Yes—Google Chat webhook 401 Unauthorized is always an authentication problem because (1) the endpoint can’t validate the credentials you sent, (2) you sent no credentials at all for that endpoint, or (3) you used the wrong authentication model for the endpoint you’re calling.

To better understand why 401 feels confusing in practice, you need to separate “authentication” into credential validity, credential type, and request target.

In real integrations, developers often believe they “have auth” because they possess some token, but the endpoint is enforcing a different scheme. An incoming webhook expects its own URL-embedded credentials (key and token), while the Chat API expects OAuth access tokens with correct scopes. If you send the right payload to the wrong endpoint, the server correctly answers “I don’t know who you are” (401), even if you are authenticated elsewhere.

A second reason 401 can mislead is that automation platforms sometimes hide the real HTTP response body and only show a short “Unauthorized” message. That leads you to rotate secrets or regenerate webhooks unnecessarily, when the actual issue is a mistaken endpoint, a URL encoding bug, or a “dev/stage/prod” mismatch.

Finally, 401 can be self-inflicted when Google Chat is calling your app endpoint (event delivery), and your app returns 401 because it can’t validate the bearer token in the Authorization header. In that scenario, Google is authenticated, but your service refuses to accept it until your verification logic and permissions are aligned.

Should you treat 401 differently from 403 when debugging Google Chat delivery?

401 wins for “identity missing/invalid,” while 403 is best for “identity known but not permitted,” and 429 is optimal for “rate-limited, retry later.”

More specifically, you should treat 401 as a “credentials and endpoint” investigation, and 403 as a “permissions and policy” investigation.

• 401 Unauthorized / UNAUTHENTICATED usually means: wrong auth model, wrong token, expired token, malformed header, revoked secret, or corrupted webhook URL.
• 403 Forbidden / PERMISSION_DENIED usually means: the caller is recognized but blocked by IAM, Workspace policy, space restrictions, or app permissions.
• 429 Rate Limit means: you’re authenticating correctly, but you’re sending too many requests too quickly.

This distinction matters because it changes the order of operations. For 401, regenerating permissions won’t help if you’re calling the wrong endpoint. For 403, rotating tokens won’t help if your org policy blocks bots or external services.

What does “Google Chat webhook 401 Unauthorized” mean in plain terms?

Google Chat webhook 401 Unauthorized is an HTTP authentication failure where the receiving service rejects your request because it can’t validate your identity for that specific endpoint, typically due to missing/invalid key+token or missing/invalid OAuth credentials.

Next, it helps to translate that into a concrete mental model: a webhook URL is a credential, and so is an OAuth access token—your job is to pair the right credential with the right destination.

If you’re posting to an incoming webhook URL, Google Chat expects the URL to contain credentials (key and token) and expects you to POST a valid message payload to that URL. If the URL is incomplete, modified, URL-encoded incorrectly, or replaced with a different endpoint, Chat can’t validate it and returns 401.

If you’re using the Google Chat API (for message creation/management under a bot or user identity), then Chat expects an OAuth 2.0 access token in the Authorization header with appropriate scopes. If that Authorization header is missing or wrong, a 401 is the natural outcome.

If Google Chat is calling your app endpoint (interactive Chat app events), Google includes a bearer token in the Authorization header, and your service is expected to validate it. When validation fails, your service should respond 401 to indicate the token did not verify.

Which part is rejecting you: the Google Chat incoming webhook endpoint or your own Chat app endpoint?

There are 2 main “rejectors” to consider: (A) Google Chat’s incoming webhook endpoint and (B) your own Chat app endpoint, based on where the HTTP request is being sent and where the 401 is generated.

Then, once you identify the rejector, you stop guessing and start checking only the variables that matter.

A) Google Chat incoming webhook endpoint rejects you when:

• Your integration is doing an HTTP POST directly to a chat.googleapis.com/.../messages?...key=...&token=... style URL.
• You see 401 in the tool that sends outbound notifications (CI, monitoring, workflow, custom code).
• Retrying with the correct saved webhook URL fixes it immediately.

B) Your own Chat app endpoint rejects Google when:

• Google Chat is sending event payloads to your HTTPS endpoint (Cloud Run, Cloud Functions, server, API gateway).
• Your logs show your server returning 401 because bearer token verification fails.
• The fix is in your verification logic, IAM, or endpoint configuration—not in the webhook URL.

A fast test is to look at the destination host: if it’s Google’s endpoint, your webhook URL/credentials are in question; if it’s your domain, your verification and hosting permissions are in question.

Are you using the correct authentication method: incoming webhook key/token or OAuth?

No—you’re not using the correct method if you’re trying to solve a webhook problem with OAuth (or an OAuth problem with a webhook URL), and this mismatch causes 401 for at least three reasons: the endpoint enforces a different scheme, credentials don’t map across products, and scopes don’t apply to incoming webhooks.

To better understand the fix, you must make a clean choice: incoming webhook for simple posts, or Chat API OAuth for API-driven bot/user actions.

Google Chat incoming webhooks are designed for a specific capability: send asynchronous messages into a space using a webhook URL that contains key and token.

The Google Chat API authentication model is different: it’s OAuth-based and is intended for Chat apps and API requests with explicit authorization and scopes.

The most common developer trap looks like this: you copy an incoming webhook URL, but your code or tool is actually configured to call a “Chat API send message” endpoint that expects OAuth. The server returns 401, and you lose hours rotating the wrong secret. The reverse also happens: you obtain an OAuth access token, but you post to the incoming webhook URL and also attach an Authorization header that your tool “helpfully” adds—this doesn’t convert the webhook into an OAuth endpoint; it just adds noise.

What’s the difference between an incoming webhook and the Google Chat API for sending messages?

Incoming webhooks win for simple “post a notification,” the Google Chat API is best for authenticated bot/user actions with scopes, and Chat app event-driven messaging is optimal for interactive experiences that need two-way communication.

However, the key to avoiding 401 is not feature comparison—it’s credential-to-endpoint alignment.

Incoming webhook (key/token in URL):

• Purpose: quick outbound notifications to a space.
• Credential: key and token embedded in the URL.
• Typical failure pattern: URL gets truncated, encoded, or swapped; token leaked/rotated; wrong environment.

Google Chat API (OAuth):

• Purpose: programmatic actions requiring authorization (bot/user identity).
• Credential: OAuth 2.0 access token in Authorization header, with correct scopes.
• Typical failure pattern: missing header, expired token, wrong audience, wrong scopes, service account misconfig.

Chat app receiving events (bearer token verification):

• Purpose: Chat calls your endpoint for interactions.
• Credential: bearer token from Google in Authorization header; your service verifies it.
• Typical failure pattern: your verification code rejects valid requests, or platform permissions block invocation.

When should you use key/token, and when should you use OAuth/service account?

There are 3 main choices based on your goal: (1) key/token for “space notifications,” (2) OAuth user flow for “act as a user,” and (3) OAuth/service account for “act as an app/bot,” depending on the specific Google Chat API features you need.

More importantly, picking the wrong one is a direct path to 401.

Use incoming webhook key/token when:

• You only need to post messages to a known space.
• You don’t need to manage spaces, users, or message lifecycle via API.
• You want minimal setup and don’t want OAuth token rotation.

Use OAuth (Chat API) when:

• You need Chat API features that require scopes and authorization.
• You need programmatic control beyond basic posting.
• You can manage token issuance, refresh, and secure storage.

Use Chat app event flow when:

• You need interactive buttons, commands, dialogs, or event-driven logic.
• You can host a secure endpoint and verify Chat requests properly.

A reliable rule: if the “credential” is a URL (with key/token), treat it like a password; if the credential is a bearer token, treat it like OAuth and manage lifecycle accordingly.

Is your incoming webhook URL valid, current, and unmodified end-to-end?

Yes—your incoming webhook URL must be valid, current, and unmodified because (1) the URL includes the key and token that authenticate the request, (2) any truncation or encoding breaks verification, and (3) old/regenerated tokens instantly invalidate previous URLs.

Then, once you accept that the URL is the credential, you stop pasting it into places that “helpfully” rewrite URLs.

A practical reality: if your webhook URL leaks into logs, repos, screenshots, or chat, you should assume compromise and rotate/regenerate it.

A second reality: even if you never leak it, your own systems can corrupt it:

• A secrets manager that trims at &.
• An environment variable that strips %3D.
• A YAML parser that treats ? and & as special unless quoted.
• A UI that “URL-decodes” and then re-encodes differently.

The result is a webhook URL that looks visually similar but is not byte-for-byte identical to the original. The endpoint checks the actual token value, not your intention.

Which webhook URL mistakes most often cause 401 (copy, encoding, truncation, environment mix-up)?

There are 6 common webhook URL mistakes that cause 401: truncation, partial copy, URL decoding/encoding changes, wrong space URL, wrong environment URL, and secret storage that strips query parameters.

Specifically, these show up repeatedly in real-world tooling and CI pipelines.

1. Truncation at &token=
   Many tools display long URLs and copy only part of the string. If token is missing, 401 is expected.
2. Double-encoding or decoding the token
   If your token contains %3D (common for base64-ish strings), decoding it and saving the decoded value can break future requests.
3. Dev/stage/prod mismatch
   You test with a webhook from “dev space,” then deploy with “prod code” but accidentally still reference the dev secret.
4. Invisible whitespace
   Trailing spaces/newlines in environment variables are notorious; the HTTP library may send the wrong URL.
5. Wrong space / wrong webhook
   Teams create multiple webhooks in multiple spaces; a copied URL might point to a space you no longer have access to.
6. Secrets manager or config format issues
   YAML without quotes, .env without escaping, or UI fields that sanitize URLs can mutate query parameters.

A quick defense is to store the webhook URL as a single, quoted value, and validate it on app startup by checking that it still contains both key= and token=.

Can secret rotation or webhook regeneration break existing integrations immediately?

Yes—secret rotation or webhook regeneration can break integrations immediately because (1) the old token can become invalid the moment a new webhook is created or policies change, (2) cached configurations keep using the old URL, and (3) distributed systems deploy at different times.

In addition, rotation often creates a false sense of “we fixed it,” when you actually introduced partial rollout failures.

If your integration runs across multiple environments (workers, lambdas, build agents, on-prem cron), you can end up with a split-brain: half the fleet uses the new URL and works, half uses the old URL and returns 401. That’s why you should treat webhook updates like deployments:

• Update secret centrally.
• Redeploy or restart all senders.
• Remove the old secret from any fallbacks.
• Audit logs to ensure no one is still calling the old URL.

If you see “works when I click Test, fails when automated,” that’s often because “Test” runs in a UI with the latest configuration, while automation runs on an agent that still has the old secret.

Are you accidentally sending to a Chat API endpoint while using a webhook URL (or vice versa)?

Yes—this mix-up is one of the top causes of 401 because (1) Chat API endpoints often require OAuth and reject webhook-style calls, (2) incoming webhooks ignore OAuth scopes and rely on key/token in the URL, and (3) tools frequently abstract endpoints and hide the difference.

However, once you learn the “telltale signs,” you can spot the mismatch in seconds.

The simplest way to avoid this is to label the integration at the architecture level: “This system posts to an incoming webhook URL” or “This system uses the Chat API with OAuth.” If you keep it vague (“posts to Chat”), future maintainers will try to “upgrade” it and accidentally switch endpoints.

When a tool asks for an “API URL,” developers sometimes paste a webhook URL into a field that is actually configured for OAuth. Or they paste a Chat API URL into an “incoming webhook” module and wonder why it demands a bearer token.

What are the telltale signs you’re mixing webhook credentials with OAuth endpoints?

Mixing webhook credentials with OAuth endpoints is indicated by 3 clear signs: error text that mentions OAuth access tokens, requests missing an Authorization header where one is required, and URLs that don’t contain key and token even though you think you’re using a webhook.

More specifically, look for these patterns.

• Error text like “Expected OAuth2 access token”
  This almost always means you’re calling an endpoint that expects OAuth, not a webhook.
• A “Chat API module” that asks for scopes or OAuth connection
  If it’s asking for scopes, you’re in OAuth land. Webhooks don’t ask for scopes.
• Your URL lacks both key= and token=
  Incoming webhook URLs include those parameters; if they’re missing, you’re not using an incoming webhook URL.
• You have an OAuth token but you’re posting to a URL that already contains key/token
  Adding an Authorization header doesn’t convert a webhook endpoint into a Chat API endpoint; it usually just adds confusion.

Is your request format correct for the method you chose?

Yes—your request format must match the chosen method because (1) incoming webhooks expect a specific JSON message payload, (2) the wrong Content-Type or body structure can cause request rejection and misleading error handling in tools, and (3) bad formatting can mask the real issue when you’re already near an auth boundary.

Next, treat request format as “the second lock” after authentication: even with perfect credentials, a malformed request won’t deliver.

A surprising number of webhook “auth” incidents are actually layered failures: the URL is correct, but the payload is invalid, the tool retries, you hit limits, and then the integration UI displays only the first failure it saw. That’s why you should validate request format early, even when the error says 401.

This is also where google chat data formatting errors often appear as a related cluster of issues: your message payload might be invalid JSON, missing required fields, or structured for a different message type than the webhook supports.

Which headers and payload fields are required for an incoming webhook POST?

An incoming webhook POST requires 3 essentials: Content-Type: application/json, a valid JSON body, and a message field structure supported by incoming webhooks—most commonly a plain text message body—otherwise the request can fail even when the webhook URL is correct.

To illustrate, you should check the simplest possible baseline before adding cards, threads, or rich formatting.

• Method: POST
• Header: Content-Type: application/json
• Body: valid JSON (no trailing commas, no stringified JSON wrapped in quotes)
• Fields: start with the smallest supported message shape (often a single text property in a JSON object), then add complexity gradually.

If your tool is sending form-encoded data or wrapping JSON inside a string field, the receiving endpoint may reject it. In some automation systems, a payload mistake can be presented as a generic failure even if the underlying server response includes more detail.

Which payload or header mistakes look like authentication failures in automation tools?

There are 5 payload/header mistakes that frequently look like “auth” failures in automation tools: wrong Content-Type, JSON stringification, missing body, invalid UTF-8/encoding, and tool-added Authorization headers that override expected behavior.

More importantly, these mistakes become common when you copy examples from a different API context.

1. Content-Type missing or incorrect
   Some systems send text/plain by default; the receiver expects JSON.
2. Stringified JSON instead of JSON
   The body becomes "{"text":"hi"}" instead of { "text": "hi" }.
3. Empty body due to templating errors
   A variable resolves to blank, tool sends {} or nothing.
4. Encoding issues
   Special characters can cause parsing failures or signature mismatches in strict processors.
5. Conflicting Authorization headers
   Some HTTP modules auto-add OAuth tokens; for a webhook call, that header is unnecessary and can confuse debugging.

This is also where the linked phrase google chat webhook 400 bad request often enters the troubleshooting conversation: once authentication is correct, formatting errors tend to surface as 400-level responses, and teams confuse these neighboring failures as one bug.

If Google Chat is calling your bot endpoint, are you verifying Chat requests correctly?

Yes—if Google Chat is calling your bot endpoint, you must verify Chat requests correctly because (1) Chat includes a bearer token in the Authorization header, (2) your endpoint must verify the token to trust the request, and (3) incorrect verification logic causes your service to return 401 even when Google is behaving correctly.

Then, once verification is correct, you can focus on higher-level logic like event parsing and responses.

Google’s guidance for Chat request verification is explicit: Chat sends a bearer token in the Authorization header of requests to your endpoint.

That means a 401 could be your application’s security feature working as designed, but misconfigured.

This is the most important mindset shift: when your endpoint returns 401, the “bug” is usually inside your endpoint, not in Google Chat. Your job is to verify the token and ensure the request is actually from Google Chat and intended for your service.

Should your bot endpoint return 401 when the bearer token verification fails?

Yes—your bot endpoint should return 401 when bearer token verification fails because (1) it signals authentication failure, (2) it prevents processing spoofed requests, and (3) it protects your downstream systems from unauthorized traffic.

In addition, this behavior makes debugging cleaner: you can log “verification failed” rather than silently dropping requests.

A safe pattern is:

• Return 401 when the token is missing or invalid.
• Return 403 when the token is valid but the request is not allowed by your own policy.
• Return 400 when the request is authenticated but malformed.

The goal is clarity: your logs should show whether the token is missing, invalid, or failing claims validation (issuer/audience/expiry).

What platform permissions can cause your endpoint to reject Chat even when tokens are valid?

There are 4 common platform permission blockers that cause your endpoint to reject Chat even when tokens are valid: service-level invocation permissions (e.g., Cloud Run/IAM), API gateway policies, network access controls, and org-level security layers that intercept or rewrite headers.

Moreover, these issues often present as 401 because the request never reaches your application code in the way you expect.

• Cloud Run invoker/IAM blocks unauthenticated invocation or requires a specific principal.
• API Gateway / Load balancer auth layer denies requests before your app logic runs.
• IP allowlists / WAF rules reject requests from Google infrastructure.
• Corporate TLS inspection / proxy strips or alters the Authorization header.

When you suspect a platform layer, compare what arrives at the edge (gateway logs) with what your app code sees. If the Authorization header is missing by the time it reaches your code, your verification will fail even though Google sent it correctly.

What’s the fastest step-by-step checklist to fix Google Chat webhook 401?

The fastest method is a 7-step decision checklist that isolates endpoint type, confirms the correct auth model, validates webhook URL integrity, verifies request formatting, and checks logs—so you can move from “401” to successful delivery in one pass.

Let’s explore the checklist in a strict order, because skipping steps creates loops.

Before you start, write down one sentence: “This integration posts to (incoming webhook URL / Chat API OAuth / Chat app endpoint).” If you can’t fill that in confidently, your first task is discovery—not debugging.

Now apply the checklist:

1. Identify who is making the request (your system or Google Chat).
2. Identify the destination host (Google endpoint or your domain).
3. Confirm the authentication model expected by that destination.
4. Validate the credential source (where key/token or OAuth token comes from).
5. Validate the exact URL and headers sent (no mutation).
6. Validate payload shape and Content-Type.
7. Confirm results with a controlled test, then roll out safely.

If you’re building internal docs, label this section as your google chat troubleshooting runbook entry so teams reuse the same mental model instead of improvising every time.

Which 5 checks solve most 401 cases in under 10 minutes?

There are 5 checks that solve most Google Chat webhook 401 Unauthorized cases: endpoint classification, correct auth model selection, webhook URL integrity verification, environment/source-of-truth validation, and minimal request replay with clean headers.

Then, once these are done, you only escalate to edge cases if necessary.

• Check 1: Endpoint classification
  Am I posting to Google (incoming webhook / Chat API), or is Google calling me (Chat app endpoint)?
• Check 2: Auth model selection
  Webhook URL (key/token) or OAuth? Don’t mix them.
• Check 3: Webhook URL integrity
  Does the URL still contain both key and token exactly as generated?
• Check 4: Environment/source-of-truth
  Is the secret coming from the right place (prod secret, not dev)? Is it cached?
• Check 5: Minimal request replay
  Send a minimal JSON message with Content-Type: application/json and no extra headers, then layer complexity back in.

If these five checks don’t reveal the root cause, it’s usually because a platform layer (proxy, gateway, IAM) is involved.

How do you confirm the fix and prevent the 401 from coming back?

You confirm the fix and prevent recurrence by (1) validating the exact request bytes in logs, (2) deploying a single source of truth for the webhook URL or OAuth configuration, and (3) enforcing safe rotation and retry policies.

In addition, you should protect the webhook URL like a credential, because it is one.

• Store webhook URLs in a secrets manager (not in code).
• Redact webhook URLs from logs (mask token).
• Validate configuration at startup (check URL contains key and token).
• Add a health check that sends a controlled message to a test space.
• Use conservative retry strategies with caps and jitter when failures happen.

If you also deal with rate limits or transient errors, remember: aggressive retries can amplify failures. Safe retries are part of reliability, not just performance.

Contextual Border: At this point, you’ve fully solved the primary intent—correctly diagnosing and fixing Google Chat webhook 401 Unauthorized by aligning endpoint, credentials, and request shape. The next section expands into rarer causes, prevention hygiene, and adjacent error patterns.

What are the less common (but real) causes of intermittent 401, and how do you mitigate them?

There are 6 less common causes of intermittent Google Chat webhook 401 Unauthorized: stale secret caching, proxy/TLS inspection changes, partial fleet rollout, URL rewriting, multi-tenant tool behavior, and hidden credential overrides—each requiring a mitigation that stabilizes configuration and preserves request integrity.

Next, treat intermittent 401 as a systems problem rather than a single request problem.

Intermittent 401 usually means “some requests are different from others,” even if your code looks the same. In distributed systems, differences hide in:

• which instance sent the request,
• which config version it loaded,
• which network path it took,
• which secret store it queried,
• which tool module executed the call.

That’s why the best mitigation is observational: you need to capture enough metadata to compare “working” versus “failing” requests without leaking sensitive tokens.

Can proxies, SSL inspection, or URL rewriting turn a working webhook into a 401?

Yes—proxies, SSL inspection, and URL rewriting can turn a working webhook into 401 because (1) they can strip or rewrite query parameters, (2) they can normalize or decode tokens differently, and (3) they can block or reroute requests based on security policies.

Moreover, these systems often change without your application deploying, which creates the illusion of randomness.

If your org uses outbound proxies, verify:

• The proxy is not truncating URLs beyond a certain length.
• Query parameters are preserved exactly.
• Requests are not being redirected to a different host.
• TLS inspection is not causing client libraries to downgrade or behave differently.

A classic symptom is: “Manual test works from my laptop, automation fails from the data center.” That usually indicates different network layers, not different credentials.

How do dev/stage/prod secrets and caching create “random” UNAUTHENTICATED errors?

Dev/stage/prod secret drift and caching create random UNAUTHENTICATED errors because (1) some instances read new secrets while others keep old ones, (2) secrets rotate without synchronized restarts, and (3) multi-environment tooling accidentally points to the wrong space.

Specifically, look for uneven rollout.

• A worker pool where only newly restarted workers pick up the updated webhook URL.
• A CI runner image that bakes in an old secret.
• A “global” environment variable overridden by a per-job secret.
• A shared automation template copied across teams with different spaces.

Mitigation checklist:

• Force a full restart/redeploy after secret rotation.
• Add a config version stamp to logs (not the secret itself).
• Keep separate secrets per environment and name them clearly.
• Add guardrails: reject startup if prod points to a non-prod space.

What should you log (and what should you never log) when investigating 401?

You should log request metadata but never log secrets, because (1) webhook URLs contain tokens, (2) OAuth tokens enable impersonation, and (3) logs are frequently copied and retained.

In addition, safe logging makes debugging faster because it removes fear and friction.

Log safely:

• Timestamp, instance ID, environment, request destination host/path (without sensitive query values).
• HTTP status code, response headers that are safe, and sanitized response body summaries.
• Whether key and token were present , not their values.
• A hash of the URL (one-way) if you need to detect drift.

Never log:

• Full webhook URLs.
• OAuth access tokens or refresh tokens.
• Authorization headers.
• Raw payloads that include secrets.

Which related errors should you differentiate from 401 to avoid chasing the wrong fix?

There are 4 related errors to differentiate from 401: 400 Bad Request, 403 Forbidden, 404 Not Found, and 429 Rate Limit—because each implies a different root cause and a different fix order.

To sum up, treating them all as “auth issues” wastes time.

• 400 Bad Request: your payload or headers are malformed, and this is where google chat webhook 400 bad request commonly points to JSON/body issues.
• 403 Forbidden: permission/policy problem, even if auth is valid.
• 404 Not Found: wrong endpoint path or the resource doesn’t exist.
• 429 Rate Limit: too many requests; implement backoff and caps.

According to a study by Stony Brook University from the Department of Computer Science, in 2016, researchers showed that classical exponential backoff can have poor worst-case throughput and proposed a variant that achieves expected constant throughput while requiring only a polylogarithmic number of access attempts per process—supporting the idea that careful retry strategies reduce wasted failed attempts when systems are under pressure.