Backend Logs

Backend logs are stored in the Curator database and can be viewed through the Curator backend interface. These logs are designed for day-to-day monitoring and auditing by administrators who may not have direct server access.

​

Usage Log

The Usage Log serves as an audit trail for your Curator instance, tracking who made what changes and when. This includes configuration changes, content modifications, user management actions, and administrative operations. The Usage Log is essential for compliance, security auditing, and troubleshooting issues caused by configuration changes.

​

Viewing the Usage Log

2. Use the filters to search for specific users, date ranges, or action types.

​

Usage Log Retention

The Usage Log retention period can be configured in Portal Settings:

2. Find the Usage Log Retention setting.
3. Select the desired retention period (1 Month, 3 Months, 6 Months, or 12 Months).
4. Click Save.

Older usage log entries will be automatically purged based on this setting.

​

Event Log

The Event Log records system events including errors, warnings, informational messages, and debug output. This is the primary log for troubleshooting issues with your Curator instance.

​

Debug Modes

Curator provides several debug modes that can drastically increase the amount of logging in the Event Log. These modes are useful for troubleshooting specific integrations or features:

• Tableau Debug Mode - Detailed logging for Tableau Server/Cloud communication
• Power BI Debug Mode - Detailed logging for Power BI integration
• Cron Debug Mode - Detailed logging for scheduled tasks
• And others depending on your enabled features

Debug modes should typically only be turned on temporarily while troubleshooting, as they can significantly increase the volume of log entries.

​

Viewing the Event Log

2. Click on any entry to view its details, including the full message and any associated context data.

​

Redacted Values

Curator automatically removes sensitive values from Event Log entries before they are saved. Passwords, password reset keys, session cookies, API keys, and authorization headers are replaced with [redacted] in both the entry message and its detail data. This happens for every entry, whichever part of Curator recorded it, so [redacted] appearing in place of a value is expected and does not indicate a problem. If you are troubleshooting an issue that depends on one of these values, reproduce it with a test account rather than looking for the original value in the log.

​

Download Debug Package

The Event Log page includes a Download Debug Package button that bundles various logs and system information into a single downloadable archive. This package is useful when reporting issues to InterWorks Support, as it includes:

• Recent event log entries
• System log files
• System configuration information

To download the debug package, click the Download Debug Package button in the toolbar on the Event Log page. The logs in this package carry the same redaction described above, so credentials are not included in what you send to InterWorks Support.

​

Event Log Retention

The Event Log retention period can be configured in Portal Settings:

2. Find the Event Log Retention setting.
3. Select the desired retention period:
   • Never (Manual) - Logs are not automatically purged; use the Event Log interface to manually clear entries
   • 1 Week - Entries older than 7 days are automatically purged
   • 2 Weeks - Entries older than 14 days are automatically purged
   • 1 Month - Entries older than 30 days are automatically purged
   • 3 Months - Entries older than 90 days are automatically purged
4. Click Save.

When automatic purging is enabled, old event log entries are removed daily at 2:00 AM (server timezone).

​

Event Log Growth Alert

Once a day, Curator counts how many Event Log entries were created in the previous 24 hours and compares that count against the Event Log Growth Threshold. If the count is higher than the threshold, a warning appears on the Status page, for example:

Event logs increased by 2500 in the last 24 hours. This exceeds the threshold of 1000, and is more than the preceding 24 hours’ growth of 800.

The check runs at the Cron Time of Day set under Portal Settings > General. A sudden rise in Event Log entries usually means something is repeatedly logging errors or that a debug mode was left on, so review the Event Log to find the cause. The warning clears on its own the next time the check runs and finds the count at or below the threshold. Emptying the Event Log from the Event Log page also runs the check again right away.

​

Changing the Threshold

2. Find the Event Log Growth Threshold setting. The default is 1000.
3. Enter the number of Event Log entries per 24 hours that should trigger the warning. The minimum is 1.
4. Click Save.

Changing the threshold does not clear a warning that is already showing. If you raise the threshold above the count that triggered the warning, the Status page notes the threshold that was in effect when the warning was raised and that the warning will clear the next time the growth monitor runs. If the warning is still showing even though its count does not exceed the threshold, and the threshold was not raised, the Status page asks you to confirm the scheduler is running.

​

Request Log

The Request Log counts requests that led to an Access Denied (403) or Not Found (404) page. It has one row for each URL and status code, with a count of how many times that URL was requested. Most entries come from bots that scan for files that belong to other platforms, so these requests are kept out of the Event Log. The Request Log does not record which user made each request. For a signed-in user, the System Log has a warning with the user’s name. Access Denied (403) requests also appear in the access-denied report on the backend Activity page.

​

Turning Request Logging On or Off

The Request Log records requests only while Log bad requests is on. It is off by default.

2. Use the Log bad requests switch above the list. The text next to the switch shows On, or Off, not recording.

Only backend users with the Manage Bad Request Logging permission see the switch. Superusers have it automatically.

​

Viewing the Request Log

2. Sort by Counter to find the URLs that were requested most often.
3. Click Empty request log to remove every entry.

​

Admin Access Log

The Admin Access Log tracks backend administrator logins and activity. This is useful for security auditing and compliance purposes.

​

Viewing the Admin Access Log

2. Review administrator access history including login times and IP addresses.

​

Alert Log

The Alert Log aggregates recurring system alerts into a single, manageable view. Rather than creating duplicate event log entries for the same recurring issue, the Alert Log consolidates these alerts and tracks how many times they have occurred.

​

Viewing the Alert Log

Alert Log entries are displayed in two locations:

1. Status Page - Here you can see active alerts alongside other system health information.
2. Alert Log List - This provides a detailed view where you can:
   • View all active, resolved, and suppressed alerts
   • See occurrence counts and timestamps
   • Mark alerts as resolved or suppressed
   • Clear alerts in bulk

​

Alert Statuses

• Active - The alert is current and requires attention
• Resolved - The underlying issue has been addressed
• Suppressed - The alert has been acknowledged but hidden from the active view

​

Tracking end-user content views

The logs above are scoped to administration. The Usage Log records configuration and content changes, the Event Log records system events and errors, and the Admin Access Log records backend administrator logins. None of them record which frontend user opened which Tableau, Power BI, or other BI Dashboard. If you are asked for a “who viewed what” report, use one of the sources below instead.

​

Curator Activity page

Curator writes one content view record each time a frontend user opens a piece of content, including Tableau Dashboards, Power BI Reports, Pages, and Files. The Activity page charts those records and can be filtered by date range, content item, and user. To export the underlying records, read the interworks_usermgmt_content_view table through the Curator API. Each row holds the username, the content type and ID, the requested path, and a timestamp. See Retrieving Usage Data.

​

Analytics Tracking

If you already use Google Analytics 4, Google Tag Manager, or Matomo, connect it under Portal Settings > Analytics. Curator then sends page views and Dashboard interaction events, such as filter changes and exports, to that platform and tags each one with the logged-in user’s analytics_id. That value is a non-personal UUID rather than the username, and the User API lets you map it back to a Curator user. See Analytics Tracking.

​

BI platform audit logs

The BI platform keeps its own access records, and those cover every client, not only Curator. For Tableau, the administrative views and the Tableau Server repository report which user viewed which view or workbook. For Power BI, the Power BI activity log and the Microsoft Purview audit log record per-user report access. Depending on how Curator authenticates to the BI platform, those records may attribute a view to the account Curator embeds with rather than to the individual user, so use Curator’s own content view records when you need the Curator username.