Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Forum Discussion
Service Account Rate Limits: 15+ Minutes Block, No Backoff Duration Shown
Environment:
- 1Password CLI (latest)
- Service Account (not personal account)
- Linux systemd service using LoadCredentialEncrypted
- op inject to load 2 secrets at startup
---
The Problem
My systemd service uses a 1Password service account to inject 2 secrets at startup via op inject. While debugging an unrelated configuration issue, I restarted the service
approximately 15 times over 10 minutes. This triggered a rate limit that has now persisted for over 15 minutes with no sign of clearing.
The Error Message
[ERROR] 2026/01/31 22:35:22 Too many requests. Your client has been rate-limited. Try again in seconds
Note the blank where the number should be — there's no indication of how long to wait.
Observed Behavior
┌──────────────────┬────────────────────────────────────┐
│ Operation │ Result │
├──────────────────┼────────────────────────────────────┤
│ op whoami │ ✅ Works (authentication succeeds) │
├──────────────────┼────────────────────────────────────┤
│ op vault list │ ❌ Rate limited │
├──────────────────┼────────────────────────────────────┤
│ op inject │ ❌ Rate limited │
├──────────────────┼────────────────────────────────────┤
│ op read op://... │ ❌ Rate limited │
└──────────────────┴────────────────────────────────────┘
This indicates the rate limit is applied per-operation-type — authentication endpoints work fine, but any vault/item access is blocked.
Issues
1. Rate limit is extremely aggressive — ~15 requests over 10 minutes triggered a 15+ minute block. This is a typical debugging session, not abuse.
2. No backoff duration shown — The error says "Try again in seconds" but the actual number is missing. I have no idea if I should wait 1 minute or 1 hour.
3. No way to check status — There's no op rate-limit-status command or API to check current quota/reset time.
4. Service accounts should have higher limits — These are designed for automation and CI/CD where rapid retries during debugging are expected behavior.
5. Disproportionate impact — A brief debugging session can take down production services for an extended period with no recourse.
Expected Behavior
- Show the actual backoff duration in the error message
- Faster reset — 1-2 minutes, not 15+
- Higher thresholds for service accounts — differentiate from potential abuse patterns
- Rate limit status endpoint — let us query current quota and reset time
- Graduated response — warn before hard blocking, or use exponential backoff instead of a cliff
Workaround
Wait and hope. There's no way to know when access will be restored.
---
Request: Can someone from the 1Password team clarify the rate limit policy for service accounts and whether the blank duration in the error message is a known bug?
2 Replies
1Password rate‑limiting is the kind of "enterprise security feature" that makes you want to take your laptop, walk into the sea, and let the tide solve your problems
You buy the secrets management control plane (the thing that's supposed to be the adult supervision for autonomous agents) and it turns into a bouncer at your own front door going:
"Whoa, whoa, mate, too many requests… come back later."Congratulations -- your "secure mediation layer" just turned into a chaos generator that makes your agent look incompetent and your infrastructure tool
The one job is: **be boring under pressure**.Not "be a surprise traffic cop when the user is already dealing with rate limits somewhere else."
When you rate-limit the credential plane, you're not protecting me -- you're stranding me mid‑operation with a half‑built robot and a pile of broken glass.
Rate limits are fine. But if you're going to throttle, at least
- give a real retry-after
- make failures explicit and atomic
- don't turn normal automation into an improv comedy about authorization headers.
Right now it's less "security" and more "a seatbelt that randomly punches you in the throat.
Look at what Doppler offers
Action Doppler 1Password
Read Requests 240 to 480 per minute 1,000 per hour
Write Requests 60 to 120 per minute 100 per hourDaily Hard Cap None (Usage-based) 1,000 requests per 24 hoursScopePer Project/EnvironmentPer 1Password Account
I hate to say it but I might have to unlearn all my op command line knowledge and move to Doppler
UPDATE: Root Cause Identified
Thanks to op service-account ratelimit (which I didn't know existed until I dug through the docs), I found the actual issue:
TYPE ACTION LIMIT USED REMAINING RESET
token write 100 0 100 N/A
token read 1000 0 1000 N/A
account read_write 1000 1000 0 6 hours from now
I hit the account-wide daily limit of 1,000 requests — not the per-token hourly limit.
What Happened
I had op read commands in my .bashrc to set environment variables. Every time a shell spawned (including subshells from scripts and tools), it tried to fetch secrets. This burned through 1,000 requests without me realizing it. The Error Message Problem
The error "Your client has been rate-limited. Try again in seconds" is misleading:
1. Blank duration — the number of seconds is literally missing from the output
2. No indication of which limit — hourly token limit? Daily account limit? No way to know from the error
3. "Seconds" implies short wait — actual reset was 6 hours
The only way to diagnose this was op service-account ratelimit, which isn't mentioned in the error message.
Suggestions for 1Password
1. Fix the error message — include the actual wait time and specify which limit was hit:
Account daily limit exceeded (1000/1000). Resets in 6 hours.
2. Warn before blocking — at 80% usage, log a warning so users can catch runaway scripts
3. Consider higher limits for Families/Personal — 1,000 requests/day is tight for power users with automation
Lesson Learned
Never put op read in .bashrc. Use .bash_profile with an interactive guard:
if [[ $- == *i* ]]; then
export MY_SECRET=$(op read "op://vault/item/field" 2>/dev/null)
fi
