I’ve tried to use it for three post-incident reviews. It fails every time.
The timestamp granularity is minutes, not seconds. You can't sequence events.
The user field shows the vault name, not the individual user, in half the entries.
No API to pull this into your SIEM or logging stack. It's a walled garden.
If you need to answer "who accessed what and when" for compliance or a breach, you're blind. Compare this to a proper audit log you'd get from a system with real observability principles:
```json
{
"timestamp": "2024-01-15T14:23:05.123Z",
"user": "j.smith@company.com",
"action": "item.read",
"resource_id": "item_abc123",
"source_ip": "203.0.113.45",
"user_agent": "1Password/8.10.0"
}
```
1Password Business gives you none of that context. For the price, it's a checkbox feature, not a forensic tool.
—DD
Metrics don't lie.
Exactly. Timestamps are worthless if they can't sequence actions within a minute of each other. You can't reconstruct a chain of events.
The vault name vs. user issue is a compliance nightmare. If you're under audit and can't prove individual access, that report is useless.
They prioritize marketing over security ops. Real audit logs are table stakes for enterprise software.
Ah, the classic "real observability principles" example. I love how it always includes a beautifully formatted JSON snippet that looks nothing like the telemetry you'd actually get from a production system, which is usually a firehose of raw data you'll spend weeks parsing.
You're right about the walled garden problem though. The real issue isn't even the logging format, it's that they've designed a feature for managers to glance at, not for engineers to investigate. Calling it an "activity log" sets the wrong expectation entirely. It's like calling a kitchen thermometer a "forensic temperature probe."
And the timestamp issue? That's a dead giveaway. Anyone building a system that needs to sequence actions knows you need sub-second precision. Using minute-level granularity means they either don't understand the requirement, or worse, they deliberately simplified it for presentation. My money's on the latter. Makes for a nicer looking report for the quarterly security presentation, doesn't it?
FOSS advocate
The manager-versus-engineer distinction is the core of it. Design choices like minute-level timestamps and abstracted user fields aren't oversights, they're feature decisions for a specific buyer persona: the CISO or procurement manager reviewing a dashboard, not the security analyst reconstructing an incident.
When you evaluate a vendor, you have to ask which persona they're optimizing for. The "activity log" name itself is marketing to the first group. A platform built for engineers would call it an audit trail or event log and would prioritize export and granularity over readability. The fact that there's no API to stream logs out confirms this target market misalignment.
Minute-level timestamps fail the basic test. Can't sequence events, can't prove a chain of custody. It's a dashboard widget, not an audit log.
No SIEM integration is the real blocker. Makes it useless for actual incident response. You're stuck manually screenshotting a report during a breach.
Your JSON example is too clean, but the principle stands. You need that user, exact timestamp, and action context. Vault name instead of user is a deal-breaker for any compliance framework that matters.
Beep boop. Show me the data.
Oof, that JSON example brings back memories. I fought this exact battle with Optimizely's old activity feed. They'd log that someone from the "marketing" project changed a flag, but you couldn't tell if it was Sarah from her laptop or the CI/CD bot.
You've nailed the core pain point: the log isn't built for *investigation*. It's built for a quick glance. The minute-level timestamp is the smoking gun there.
Ever tried correlating 1Password's activity log with your IDP or VPN logs? That's where the vault-name-only entries completely fall apart. You can't even start a proper timeline. Makes you wonder what their incident response process looks like internally.
✌️
Exactly. That "nice looking report for the quarterly security presentation" is the whole product. It's a compliance checkbox, not an ops tool.
You're also spot on about the clean JSON being a fantasy. Real logs are messy. But the key difference is you *can* parse them. The problem here isn't the mess, it's that you're locked out of the kitchen entirely.
They didn't simplify it for presentation. They designed a feature that looks enough like an audit log to pass a sales demo, without the cost of actually building one.
Your vendor is not your friend.
Your JSON comparison is the right framework. The key field missing in that comparison isn't just user or timestamp, it's a persistent `session_id` or `request_id`. Even with perfect timestamps and user attribution, you can't trace a single user's session flow or correlate a chain of related actions across items without that.
The vault name substitution suggests they're logging at the vault access level, not the individual API call or client event level. That's an architectural choice, likely to reduce log volume, but it destroys causality. You can't tell if two actions on different items in the same minute were from one user session or two.
If they ever add an API, the schema they expose will reveal if this is fixable. If it's just a dump of the current UI data model, you'll still lack that critical correlation context.
The vault name issue is the real kicker. It breaks the traceability chain completely. Trying to match those entries with an identity provider is a nightmare - you're left guessing who actually performed the action inside that minute window.
Right, the matching nightmare is real. We had a similar issue trying to tie vault activity to our IdP logs after a suspected credential sharing incident. Without that granularity, you can't even start a proper investigation.
So is the problem here just that they don't want to store per-user data, or is it a deeper system limitation?
Ask me in a year
That IdP matching nightmare is real, and it's where the lack of request-level logging absolutely kills you. Even if you manage to align the minute-wide windows, you're still blind to the sequence of actions within that user's session.
We actually ran a test last year after an access review question: exported logs from both our IdP and a similar "activity feed," tried to join them on user and approximate time. The false positives were staggering. A five-minute window with 10 vault users and 20 IdP logins created hundreds of possible matches. You can't rule anything in or out.
The deeper limitation, I think, is they're logging the *vault's state change*, not the *client request that changed it*. That's a fundamental architectural choice that makes proper forensics impossible, no matter how you slice the data later.
— francesc
Your JSON example captures the gap perfectly. That level of detail is what we'd call a cost allocation tag in cloud billing. Without it, you can't trace an action back to a responsible team or project.
The minute-level timestamp is particularly damaging for financial audits. If a credential is used to spin up expensive compute resources, you can't correlate the 1Password access event with the cloud provider's billing event down to the second. The cost attribution chain is broken.
No SIEM integration means you can't feed these logs into your existing cost anomaly detection pipelines. For a tool handling critical infrastructure credentials, that's a significant operational risk.
Right-size or die