Activity is now an operations inbox for email and webhooks
The Activity page now separates operational delivery state from audit history, making webhook failures, DNS issues, bounces, and retryable actions visible in one place.
Today, August 6, 2026, we shipped a new Activity experience in Postscale.
The old page was an audit log. That made it useful for answering "who changed what?" but weak for the more urgent operational question: "what happened to my email or webhook, did anything fail, and what can I do now?"
The new Activity page separates those jobs.
- Operations shows delivery state, failures, retries, and next actions.
- Audit log keeps the security and configuration history of your organization.
Why Activity needed to change
Email infrastructure has two different kinds of history.
The first is audit history. A teammate creates an alias, an API request verifies a domain, or an admin rotates a key. Those entries matter for compliance, security review, and debugging configuration changes.
The second is operational history. A webhook endpoint returns a non-2xx status, a domain is missing a DNS record, an email bounces, or a background job gets stuck. Those events matter because they need attention.
Combining both into one raw table made the page noisy. A successful audit event and a failed delivery looked too similar, and there was no clear path from a row to the action a customer needed to take.
Operations is the default view
The Activity page now opens on Operations.
At the top, summary tiles show the current workload:
- Needs attention
- Failed webhooks
- Email submission failures
- Deferred or bounced email
- DNS attention
- Recent successes
The default filter is Needs attention, so failures and retrying work appear before routine success events.
Each operational row is normalized around the same shape: time, status, event, issue or state, and actions. That means a failed webhook, a bounced email, and a DNS verification problem can sit in one table without requiring the customer to understand the internal tables behind them.
Row actions are now part of the page
Activity is not just a log anymore. Rows expose safe actions where Postscale can take one.
For webhook delivery failures, you can:
- Retry the failed delivery
- Open the related webhook configuration
- Copy the delivery ID
- View details about the last response
For DNS issues, you can:
- Open the required DNS records
- Request a new verification check
For email events, you can:
- Open the related email area
- Inspect the delivery state
- See whether a problem is deferred, bounced, failed, or retryable
The important difference is that Activity now behaves like an inbox for operational work. If something needs attention, the row should explain the state and expose the next safe action.
Webhook retry and email retry are different
We also tightened the retry model because "retry" means different things in different parts of email infrastructure.
Retrying a webhook redelivers an event to your endpoint. If your endpoint
returned 422, timed out, or was down during a deploy, Postscale can create a
new delivery attempt for that same event. The original failed delivery remains
in history so the retry itself is auditable.
Retrying email is intentionally narrower. Postscale only exposes retry when the failure happened before the message was accepted by the Mail Transport Agent. Once the MTA accepts a message for delivery, retrying from Activity would become a resend to recipients, which is a different operation with different customer expectations. We do not treat those accepted messages as resend candidates.
That separation keeps webhook recovery useful without creating accidental duplicate email sends.
Audit log is still there, but clearer
The Audit log tab remains the place for security and configuration history.
It now uses customer-readable columns:
| Column | What it answers |
|---|---|
| When | When the action happened |
| Actor | Who or what initiated it |
| Activity | What changed or was attempted |
| Target | Which email, domain, alias, webhook, or setting was affected |
| Outcome | Whether it succeeded, failed, was blocked, or needs review |
Filters now use the same language:
- Category
- Outcome
- Source
- Search
Audit loading is also faster. Filtering, search, count, and pagination now run server-side, backed by indexes on the audit log access patterns.
Payloads stay out of the default view
Operational detail is useful, but email and webhook payloads can contain customer message content.
The Activity page therefore shows operational metadata by default: delivery ID, resource ID, endpoint, status, attempt count, next attempt time, last status code, and sanitized error information. Full payload inspection should remain a deliberate debugging action, not something exposed in every table row.
Where to find it
Open Dashboard > Account > Activity.
Use Operations for delivery state, failures, retries, and DNS checks. Use Audit log when you need the organization security trail.
For related setup details, see the Webhooks documentation, Domain Setup, and Outbound Service.