Skip to content

System Log Documentation

Menu Location: Settings > System > System Log

Access Level: Administrator and above

Last Updated: 2026-03-01

Overview

The System Log provides a comprehensive technical log of system errors, warnings, and important events. This diagnostic tool is essential for troubleshooting issues, monitoring system health, and identifying problems before they affect customers.

Primary Functions:

  • Monitor system errors and exceptions
  • Track application warnings and notices
  • Review cron job execution status
  • Diagnose performance issues
  • Identify recurring problems
  • Support technical troubleshooting

Page Layout

Header Section

  • Date Range Selector
  • Log Level Filter: Error, Warning, Notice, Info, Debug
  • Category Filter: Database, Email, Payment, Integration, Cron, etc.
  • Search: Find specific error messages or stack traces

Main Content Area

Chronological log entries with severity level, timestamp, category, message, and technical details.

Alert Dashboard

  • Critical errors requiring immediate attention
  • Error count by severity
  • Most frequent error types
  • System health indicators

Report Data & Columns

Column Description
Timestamp When event logged
Severity Error, Warning, Notice, Info
Category System component (Database, Email, Payment, etc.)
Message Error or event description
File/Line Source code location (if applicable)
User/Customer Who was affected (if applicable)
Request URL Page where error occurred
Stack Trace Technical debugging information

Log Severity Levels

Error (Critical)

  • System failures requiring immediate attention
  • Payment processing failures
  • Database connection errors
  • Critical integration failures
  • Action Required: Investigate immediately

Warning

  • Non-critical issues that may need attention
  • Deprecated function usage
  • Rate limit approaching
  • Performance degradation
  • Action Required: Review and plan fix

Notice

  • Important informational events
  • Configuration changes
  • Scheduled task completion
  • Integration status updates
  • Action Required: Review periodically

Info

  • Normal operation events
  • Successful operations
  • Audit trail information
  • Action Required: For reference only

Debug

  • Detailed technical information
  • Development/troubleshooting data
  • Action Required: Usually disabled in production

Common Use Cases

Use Case 1: Daily Error Review

Goal: Monitor system health and catch issues early

Steps:

  1. Filter to "Error" severity
  2. Set date range to last 24 hours
  3. Review all error entries
  4. For each error:
    • Determine if one-time or recurring
    • Assess impact (how many users affected?)
    • Prioritize by severity and frequency
  5. Create tickets for issues needing developer attention
  6. Document workarounds for recurring issues

Example: Morning review shows 3 "Database timeout" errors between 2-3 AM. Low impact (off-hours), but recurring pattern suggests database needs optimization. Create developer ticket.

Use Case 2: Troubleshoot Customer Issue

Goal: Investigate reported problem using system logs

Steps:

  1. Get customer name/email and approximate time of issue
  2. Search for customer identifier
  3. Filter to time range around reported problem
  4. Review errors affecting this customer
  5. Check stack trace and request URL for context
  6. Identify root cause
  7. Implement fix or workaround

Example: Customer reports checkout failed at 3:45 PM. Search shows "Stripe API timeout" at 3:44 PM for this customer's payment. Stripe status page shows brief outage. Retry customer's payment - succeeds. Issue was temporary Stripe problem, not system issue.

Use Case 3: Monitor Integration Health

Goal: Ensure external integrations are functioning

Steps:

  1. Filter to "Integration" category
  2. Review last 7 days
  3. Check for:
    • Authentication failures (expired API keys)
    • Rate limit warnings
    • Connection timeouts
    • Deprecation notices
  4. Proactively address before becoming critical

Example: Weekly review shows 15 "ActiveCampaign API rate limit approaching" warnings. Integration hitting 80% of limit. Solution: Reduce sync frequency or request limit increase from ActiveCampaign.

Use Case 4: Performance Investigation

Goal: Identify slow or problematic operations

Steps:

  1. Filter to warnings and errors
  2. Search for "timeout", "slow", "performance"
  3. Identify operations taking excessive time:
    • Database queries
    • API calls
    • Report generation
    • Email sending
  4. Review frequency and pattern
  5. Create optimization plan

Example: Multiple "Slow query detected" warnings for customer search page. All occur when searching addresses (not names). Database index missing on address fields. Add index, performance improves.

Use Case 5: Cron Job Monitoring

Goal: Verify scheduled tasks are running successfully

Steps:

  1. Filter to "Cron" category
  2. Review last 24-48 hours
  3. Check that expected jobs completed:
    • Nightly order processing
    • Email queue processing
    • Data backups
    • Report generation
  4. Investigate any missing or failed jobs
  5. Verify critical data wasn't lost

Example: Nightly backup cron job shows "Failed - disk full" error. Critical issue! Clear space immediately, verify partial backup saved, run backup manually. Set alert for disk space monitoring.

Troubleshooting

Too Many Log Entries to Review

Solutions:

  1. Filter to "Error" only (ignore warnings initially)
  2. Use search for specific error messages
  3. Export and analyze in Excel for patterns
  4. Focus on most recent or most frequent
  5. Group by error message to see frequency

Cannot Find Expected Error

Check:

  1. Expand date range (timezone issues?)
  2. Try different severity levels
  3. Search for partial error message
  4. Error may have been logged to different category
  5. Some errors may go to separate technical logs (contact sysadmin)

Error Messages Too Technical to Understand

Approach:

  1. Read message carefully for business context
  2. Note which customer or operation was affected
  3. Check if error is recurring (pattern may provide clues)
  4. Copy error message and stack trace for developer
  5. Document what customer was trying to do when it occurred

Don't Try To:

  • Fix system code without developer support
  • Ignore critical errors you don't understand
  • Delete log entries (needed for debugging)

Same Error Repeating Constantly

Urgent Action:

  1. Assess impact: How many customers affected?
  2. Check if error is blocking critical functions
  3. Review recent system changes that may have caused it
  4. Escalate to technical team immediately if high impact
  5. Implement workaround if possible
  6. Monitor for resolution
  • Admins Action History - Admin user actions (separate from system errors)
  • Email Log - Email-specific event tracking
  • Integration Logs - EasyPost, HelpScout, other specific integrations
  • System Settings - Configuration that may affect errors

Permissions & Access

Required Access Level: Administrator or higher

Access Level Capabilities:

  • Administrator: View all logs except debug, export data
  • Kiva Admin: All logs including debug, technical diagnostics, log configuration

Restricted Features:

  • Debug Level Logs: Requires Kiva Admin
  • Delete Log Entries: Generally not allowed (use archiving)
  • Modify Log Settings: Requires Kiva Admin

Best Practices

Daily Monitoring

  1. Review errors every morning (before customer calls start)
  2. Check critical integrations (payment, shipping) first
  3. Investigate new error types immediately
  4. Track recurring errors for pattern analysis
  5. Don't ignore warnings (become errors eventually)

Error Response

  1. Critical Errors (payment, database): Immediate escalation
  2. Integration Errors: Verify still functioning, retry if failed
  3. Email Errors: Check queues, verify deliverability
  4. Warnings: Document and plan fix within week
  5. Notices: Review weekly

Documentation

  1. Keep list of known recurring errors with workarounds
  2. Document root causes when identified
  3. Note which errors are safe to ignore (rare false positives)
  4. Track error trends over time
  5. Share common errors with team for training

Communication

  1. Alert team to critical errors immediately
  2. Weekly error summary for developers
  3. Update customers if errors affected them
  4. Document outages and resolutions
  5. Track error reduction as quality metric

Things to Avoid

  • Don't ignore errors hoping they'll go away
  • Don't filter out errors you don't understand
  • Don't assume one-time errors won't recur
  • Don't make system changes without understanding root cause
  • Don't delete logs (needed for long-term troubleshooting)

Quick Reference Card

Task Action
Daily error check Severity: Error, Date: Today
Find critical issues Severity: Error, Category: Database or Payment
Troubleshoot customer issue Search customer email/ID, time range around issue
Check integration health Category: Integration, last 7 days
Monitor cron jobs Category: Cron, last 24 hours
Performance problems Search "slow" or "timeout", last week
Weekly review Severity: Error + Warning, last 7 days, export

FAQs

How long are system logs retained?

Typically 30-90 days in searchable form, archived longer-term for compliance. Check with system administrator.

Should I be concerned about warnings?

Monitor warnings - they indicate potential problems. Investigate if recurring or affecting customers. Plan fixes before they become errors.

Can customers see these errors?

No - system log is admin-only. Customers see user-friendly error messages (if designed well), not technical details.

What if I see database errors?

Database errors are serious. Check if system is still functioning. Alert technical team immediately if database is down or very slow.

How do I know which errors are urgent?

Urgent: Payment failures, database connection lost, critical integration down, data loss errors Important: Email sending failures, integration authentication errors, recurring warnings Lower Priority: One-time notices, debug info, non-critical warnings

Can I customize what gets logged?

Log configuration typically requires Kiva Admin access. Can adjust severity thresholds, categories logged, and retention periods.

What's the difference between this and other logs (EasyPost, HelpScout)?

System Log covers general application errors. Other logs are integration-specific with more detailed event tracking for those services.

Change Log

2026-03-01

  • Initial documentation created

End of Documentation

For additional help, contact your system administrator or Kiva Logic support.