System log

Availability

The System Log screens ship with the new Tallyfy client and are not yet generally available. If you are on the current client at go.tallyfy.com, the System Logs item is not in your sidebar, whatever your role is. This is not a permissions problem and an Administrator cannot switch it on for you.

The data behind the screens is being collected now, so nothing is lost while you wait. When the new client reaches you, the full history described on this page is already there.

To ask for an export in the meantime, contact support with the date range and the event types you need.

What the system log shows

The System Log is an admin-only view of every customer-relevant event captured for your Tallyfy organization. It answers questions like:

“Did our webhook to the CRM fail yesterday?”
“Did the welcome email to alice@example.com get delivered or did it bounce?”
“How much did our team spend on the AI assistant last month?”
“Who tried to log in with a wrong password to my org last week?”

Three things are tracked: server-side system events, email delivery events, and AI usage events. The log is read-only. You can’t edit or delete entries from it.

The rest of this page covers how to open the log, what each of the three tabs shows, how to find and export events, and a few things worth knowing about retention and privacy.

Open the system log

Open the left sidebar and click System Logs. The page opens to the System tab by default. Use the tabs at the top to switch between System, Email, and AI Usage views.

If you don’t see System Logs in the sidebar, see Availability above. The screens are part of the new Tallyfy client, so they are missing for everyone on the current client, including Administrators. Once you are on the new client, the item is admin-only: a member or a light member will not see it.

The rest of this page describes those screens. Every instruction below (the filter chips, the Bot user preset, the Export CSV button, the Pre-auth badge, the row expander and the Refresh button) applies to the new client only.

What each tab shows

System tab

Captures events that happen inside Tallyfy’s backend on behalf of your organization. Seven categories:

Category	What it captures
Webhook	Outgoing webhook calls Tallyfy makes to your endpoints (success and failure, with HTTP status).
Email	Server-side send attempts (separate from the per-recipient delivery events on the Email tab).
Billing	Recurly payment outcomes and subscription state changes.
Security	Failed login attempts, password resets, role changes, email-address changes, and “made public” actions on blueprints and kickoff forms.
Process	Auto-archive and auto-complete actions performed by Tallyfy’s bot user against your processes and tasks.
Auth	Successful sign-ins, and the OAuth steps an outside AI app goes through to connect to your organization. Security records the attempts that failed; Auth records the ones that worked.
Audit access	Who opened or exported the System Log itself, and the filters they used.

Full list of system events

Event	Category	Meaning
`webhook_sent`	Webhook	A webhook was sent successfully (HTTP 2xx).
`webhook_failed`	Webhook	A webhook failed. The full URL and HTTP status are visible in the row.
`email_sent`	Email	Server attempted to send an email (per-recipient delivery is on the Email tab).
`email_send_failed`	Email	Server-side send attempt failed before reaching the email provider.
`smtp_send_failed`	Email	The configured SMTP transport rejected the message.
`billing_payment_succeeded`	Billing	Recurly confirmed a successful charge.
`billing_payment_failed`	Billing	Recurly rejected a charge. The reason from Recurly is visible in the row.
`billing_subscription_created`	Billing	A new subscription was created for the org.
`billing_subscription_updated`	Billing	The subscription plan or quantity changed.
`billing_subscription_expired`	Billing	The subscription lapsed (typically after repeated payment failures).
`login_failed`	Security	A login attempt for an email belonging to your org failed (wrong password, a failed multi-factor (MFA) check, and so on).
`password_reset_initiated`	Security	A password-reset email was requested for an account in your org.
`password_reset_completed`	Security	A user in your org successfully completed a password reset.
`role_changed`	Security	An Administrator changed another member’s role.
`email_address_changed`	Security	A member changed their login email.
`blueprint_made_public`	Security	An Administrator made a blueprint public (anyone with the link can view).
`kickoff_form_made_public`	Security	An Administrator published a kickoff form publicly.
`process_auto_archived`	Process	Tallyfy’s bot user auto-archived a completed process per your archive policy.
`task_auto_completed`	Process	Tallyfy’s bot user auto-completed a task per your auto-complete rules.
`login_succeeded`	Auth	A user signed in successfully. This is the row an auditor asks for first, and it is the counterpart to `login_failed` above.
`oauth_authorize`	Auth	An outside AI app started the OAuth handshake to connect to Tallyfy.
`consent_approved`	Auth	A user approved an outside AI app’s request for access to your organization.
`token_issued`	Auth	An access token was issued to an outside AI app after consent.
`system_log_viewed`	Audit access	Someone opened or exported the System Log. The user, the tab and the filters they applied are in the row.

Email tab

Per-recipient delivery and engagement events from Mailgun, the email provider Tallyfy uses. This tab is the most useful answer to “did this customer actually receive the email?”.

Event	Meaning
`email_sent`	Tallyfy handed the message to Mailgun for delivery.
`email_delivered`	Mailgun confirmed the receiving server accepted the message.
`email_failed`	A delivery attempt failed (transient or permanent).
`email_bounced`	The receiving server permanently rejected the message (invalid address, mailbox full, blocked, etc.).
`email_unsubscribed`	The recipient clicked the unsubscribe link.
`email_complained`	The recipient marked the message as spam in their mail client.
`email_send_failed`	Tallyfy couldn’t hand the message to Mailgun (rare).
`smtp_send_failed`	The custom SMTP transport (if configured) rejected the message.

AI usage tab

Captures every interaction the AI assistant or MCP tools (outside AI apps that connect to Tallyfy) have on behalf of users in your org. Events vary by interaction type (a chat message, an MCP tool call, an embedding request) but each row carries the same fields:

User that made the request
Model used (for example, Opus or Sonnet)
Prompt tokens / completion tokens / total tokens
Cost (USD) for the request
Latency (ms)
Success / error with the error message if it failed

Use this tab to track AI spend by team member, watch latency trends, and find failing requests when a user reports the AI behaving oddly.

Find and export events

Filter and search

Every tab has the same filter controls along the top. The filter panel collapses on narrow screens.

Date range picker. The screen opens on the last 90 days. That is a starting view chosen to keep the first load fast, not a limit: pick an earlier date and the picker reaches the full 18 months that are retained.
Category (System tab only) and Event type multi-select chips.
Severity (System tab only): error, warning, info.
Global search box. Free-text search across event names and error messages. It’s case-insensitive (a search for connection refused matches Connection refused).
Advanced filters (collapsible): per-column “contains” search for event name, message, recipient, and subject.
Actor picker for the user who triggered the event. There’s a “Bot user” preset that selects your org’s automation bot, so you can answer “what did the bot do this week?” in one click.
Sort by column with ascending / descending toggle.
Page size: 25, 50, 100, or 200 rows per page.

Export to CSV

Click Export CSV in the toolbar. The export uses your current filters and streams rows to a downloaded file. There’s no row cap. A 90-day window for a busy org typically exports in a few seconds.

The CSV includes the same columns visible in the table plus the full message body. Use it for compliance archives or to share specific failures with engineering.

Reading the log through the API

The same events are available through Tallyfy’s API, and there is one default worth knowing before you write anything against it.

🔴 If you omit from, you get the last 24 hours and nothing older. The default is applied by the service, silently, so a call with no date range returns a short list that looks like the whole log. It is the first thing most callers hit.

Send an explicit from (and to, if you want to bound the other end) on every call. Both accept a date. The screens in the new client always send a from for this reason, which is why they show 90 days where a bare API call shows one.

Anything up to the full 18 months of retention is reachable this way.

Good to know

Failed-login and password-reset events happen before the user is signed in, so Tallyfy can’t tag them with an org ID at capture time. The System Log resolves them to your org by matching the entered email address against your member list. So you’ll see:

Failed login attempts where the email belongs to a member of your org. This helps you spot credential-stuffing, where attackers try many stolen passwords against your accounts.
Password resets initiated for emails that belong to your org, plus the matching password_reset_completed event when the user finishes.

You won’t see:

Failed logins for email addresses that aren’t yet members of any org. Tallyfy can’t safely assign these to your org.
SSO denial events that don’t capture the attempted email.
Invitation events for an invitee who’s not yet a Tallyfy user. These are tracked separately and may be added in a later release.

A small Pre-auth badge appears next to events resolved this way, so you can tell them apart from events captured directly with your org ID.

If you want to hide pre-auth events from a search, toggle off Include pre-authentication events in the filter panel.

Who viewed the log

Every time someone opens or exports the System Log, Tallyfy records a system_log_viewed event. It shows up in the System tab itself under the Audit access category, with the user, timestamp, log type, and the filters that were applied. Filter on that category to see log reads on their own.

This is on purpose: if your org needs to know who’s been auditing, you can answer that question from inside the same UI. This record of log views is visible to all Administrators and exports normally with CSV.

How long events are kept

System events, email events and AI usage events are retained for 18 months. That is the storage policy on Tallyfy’s logging database and it applies to all three tabs. Hourly rollups used for charts are kept for three years.

The 90 days you see on screen is not the retention period. It is the window the date-range picker opens on. Set an earlier start date and you get the older events, because they are still there. An earlier version of this page called 90 days a hard cap, which was wrong and wrong in the worst direction: it told administrators their audit trail had been deleted when it had not.

If you need a history longer than 18 months for compliance, export the CSV on a schedule and archive it in your own storage. Events older than 18 months are removed and cannot be recovered.

What’s not logged

For privacy and security, the following are deliberately excluded:

Raw API request and response bodies. Use Tallyfy’s API audit trail (separate feature) if you need request-level inspection.
Internal monitoring events (uptime probes, capacity forecasts, queue health checks). These would be noise.
API keys, OAuth tokens, passwords, and session cookies. These are stripped before any event is written. We never log secrets.

Webhook URLs are returned in full because customers want to debug their own integrations. If you put a secret in a webhook URL query string, that secret will appear in the log. Use webhook signing headers instead of URL parameters for secrets.

Common questions

Why don’t I see events from before yesterday? If you are calling the API, you omitted from, and the default is the last 24 hours. Send an explicit from. On screen the picker opens on the last 90 days instead, so if you are looking at the log in Tallyfy and want something older, just set an earlier start date. Either way the data goes back 18 months.

The Email tab is empty for an email I know we sent. Two possibilities. Mailgun events arrive a few seconds after the send, so very recent emails may not have a delivery event yet (the email_sent event from the System tab will show, but email_delivered is in the Email tab and lags slightly). Or, the message was sent through your own SMTP transport, which doesn’t report delivery back to Tallyfy.

Can I see what changed in a role_changed event? Yes. Click the row to expand it. The “before” and “after” role values are in the detail panel, along with the user who made the change.

Can I get realtime updates without refreshing? The page polls when you switch back to the tab, and there’s a manual Refresh button in the toolbar. Realtime push updates are tracked as a separate feature request.

Email > What Tallyfy emails look like

Tallyfy sends 53 distinct email types across 10 categories, from sign-in and task activity to…

Emails Tallyfy Sends > Account change notices

Tallyfy automatically sends you confirmation emails whenever key account changes happen, like…

Emails Tallyfy Sends > Signing in and account access

Tallyfy sends six account-related emails covering account reactivation, welcome messages…

Miscellaneous > Glossary

A quick-reference glossary of Tallyfy platform terms. Covers templates, processes, automations…

Was this helpful?

Get in touch

About Tallyfy