sysevent Table — ServiceNow Reference

Table Reference/sysevent

The `sysevent` table stores asynchronous events created by `gs.eventQueue()` and consumed by notifications, script actions, and flow triggers. Part of Platform's event processing engine. Key gotcha: events are consumed and deleted automatically, so you'll often query an empty table in dev instances.

What This Table Is

The sysevent table is ServiceNow's asynchronous event queue, storing events created by gs.eventQueue() for background processing. These events drive notifications, script actions, and flow triggers without blocking the current transaction. Every time you fire an event with gs.eventQueue('record.insert', current), a record lands here temporarily.

Owned by the Platform module, this table supports ServiceNow's event-driven architecture end-to-end. Events get queued here, then consumed by event processors running in the background. The entire notification system, many automated workflows, and custom integrations depend on this queue functioning properly.

The sysevent table doesn't extend any parent and has no child tables. It's a standalone queue table with a unique lifecycle—records get created and automatically deleted after processing. This makes it fundamentally different from typical ServiceNow tables where records persist.

In large enterprises, this table processes thousands of events daily but typically maintains a small record count because events are consumed quickly. Performance remains good even with high throughput since the table is optimized for rapid insertion and deletion rather than complex queries.

When You'll Script Against This Table

You'll rarely query sysevent directly—most interaction happens through gs.eventQueue() in Business Rules, Script Includes, and scheduled jobs. You'll script against it when troubleshooting event processing, building monitoring tools, or creating custom event processors. Most debugging happens in Script Background or scheduled jobs.

Access requires admin role or specific event management roles. The table has restrictive ACLs since event data can contain sensitive information from any record type. Global scope scripts have full access, but scoped applications have limited event creation rights.

Monitor event backlogs during system issues
Debug why notifications or flows aren't triggering
Create custom event processors for specific event names
Build dashboards showing event processing health
Purge old events that failed to process
Analyze event patterns for performance optimization
Queue custom events for batch processing workflows

Table Gotchas

⚠️

Events are automatically deleted after processing. Your dev instance will often show zero events even when the system is actively processing them. This makes debugging timing-sensitive.

⚠️

The parm1 and parm2 fields store serialized objects, not plain text. Always use gs.eventQueue() to create events rather than inserting records directly.

The state field uses choice values: 0=Ready, 1=Processing, 2=Processed, 3=Error. Most events you'll see are state=0 waiting for processing.
Events can get stuck in state=1 (Processing) if the processor crashes. These orphaned events won't auto-retry and need manual cleanup.
The instance field tracks which node is processing the event in clustered environments. Useful for debugging node-specific issues.

⚠️

Querying large date ranges can be expensive since events are indexed primarily for quick processing, not historical analysis. Always include state filters and limit result sets.

The claimed_by field shows which background process claimed the event. Empty means unclaimed and available for processing.
Events older than 7 days get automatically purged regardless of state. Don't rely on this table for audit trails or long-term event history.

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

The sysevent table connects to sys_script_action through the event name—script actions subscribe to specific event names and execute when matching events arrive. You'll often query both tables together when debugging why script actions aren't firing. The sysevent_email_action table also processes events for notification emails.

Flow triggers in the sys_trigger table can subscribe to events, making sysevent a bridge between traditional scripting and Flow Designer. The sys_log table captures errors during event processing, so you'll cross-reference both when troubleshooting failed events. Since events can reference any table record through table and instance fields, you might join to any table in the system depending on what triggered the event.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
name	string	Event Name	The event name that triggered this record, like 'record.insert' or 'custom.approval'. Script actions and flows subscribe to specific event names.
state	choice	State	Processing state: 0=Ready, 1=Processing, 2=Processed, 3=Error. Events stuck in Processing state indicate failed processors that need manual cleanup.
table	string	Table	The table name of the record that triggered this event. Used with the instance field to identify the specific record.
instance	string	Instance	The sys_id of the record that triggered this event. Combined with table field, gives you the exact record reference.
parm1	string	Parameter 1	Serialized object containing event parameters. Don't parse manually—use gs.eventQueue() API which handles serialization properly.
parm2	string	Parameter 2	Additional serialized parameters for the event. Often contains record snapshots or custom data passed to gs.eventQueue().
claimed_by	string	Claimed By	Background process ID that claimed this event for processing. Empty means available for processing, non-empty means being processed.
process_on	glide_date_time	Process On	Earliest time this event should be processed. Allows for delayed event processing and scheduled background tasks.
processed	glide_date_time	Processed	Timestamp when event processing completed. Only set for processed or error state events before they get purged.
queue	string	Queue	Processing queue name for prioritization. Default is 'default' but custom queues can be created for different processing priorities.
source	string	Source	Application scope or source that created this event. Helps track which application or process is generating events.
user_id	reference	User ID	Reference to sys_user who triggered the event. Maintains user context for security and auditing in background processing.
uri	string	URI	URL or resource identifier related to the event. Often contains REST API endpoints or form URLs for context.
error_string	string	Error String	Error message when event processing fails. Only populated for events in error state before they get purged.
extra_info	string	Extra Info	Additional context information for the event. Format varies by event type—could be JSON, key-value pairs, or plain text.

Common Queries

Get all unprocessed events ready for processing

// Most basic query - events waiting to be processed
var gr = new GlideRecord('sysevent');
gr.addQuery('state', 0); // Ready state
gr.orderBy('sys_created_on');
gr.query();

while (gr.next()) {
    gs.print('Event: ' + gr.name + ' for table: ' + gr.table);
    gs.print('Created: ' + gr.sys_created_on.getDisplayValue());
}

Find processing errors for specific event name and user

// Debug events in error state for specific criteria  
var gr = new GlideRecord('sysevent');
gr.addQuery('state', 3); // Error state
gr.addQuery('name', 'record.insert');
gr.addQuery('user_id', gs.getUserID()); // Current user's events
gr.orderByDesc('sys_created_on');
gr.query();

while (gr.next()) {
    gs.print('Failed event: ' + gr.getDisplayValue());
    gs.print('Error: ' + gr.error_string);
    gs.print('Table/Record: ' + gr.table + '/' + gr.instance);
}

Monitor stuck events that failed to complete processing

// Real-world scenario: find events stuck in processing state
// These usually indicate crashed background processors
var gr = new GlideRecord('sysevent');
gr.addQuery('state', 1); // Processing state
var fiveMinutesAgo = new GlideDateTime();
fiveMinutesAgo.addSeconds(-300);
gr.addQuery('sys_created_on', '<', fiveMinutesAgo);
gr.query();

var stuckCount = 0;
while (gr.next()) {
    stuckCount++;
    gs.print('Stuck event: ' + gr.name + ' claimed by: ' + gr.claimed_by);
    // Reset to ready state for reprocessing
    gr.state = 0;
    gr.claimed_by = '';
    gr.update();
}
gs.print('Reset ' + stuckCount + ' stuck events');

Count events by name and state for monitoring dashboard

// Aggregate query for event processing health metrics
var ga = new GlideAggregate('sysevent');
ga.addAggregate('COUNT');
ga.groupBy('name');
ga.groupBy('state');
ga.query();

while (ga.next()) {
    var eventName = ga.name.toString();
    var state = ga.state.toString();
    var count = ga.getAggregate('COUNT');
    var stateLabel = (state == '0') ? 'Ready' : 
                    (state == '1') ? 'Processing' : 
                    (state == '2') ? 'Processed' : 'Error';
    gs.print(eventName + ' - ' + stateLabel + ': ' + count);
}

Wrong way vs right way to query recent events efficiently

// WRONG: This query is expensive on large event volumes
// var gr = new GlideRecord('sysevent');
// gr.addQuery('sys_created_on', '>', gs.daysAgo(1));
// gr.query(); // No state filter = scans processed records

// RIGHT: Always filter by state first for performance
var gr = new GlideRecord('sysevent');
gr.addQuery('state', 'IN', '0,1,3'); // Only unprocessed/processing/error
gr.addQuery('sys_created_on', '>', gs.hoursAgo(2)); // Shorter timeframe
gr.orderByDesc('sys_created_on');
gr.setLimit(100); // Always limit results
gr.query();

gs.print('Found ' + gr.getRowCount() + ' active events');

Related Tables

sys_trigger sys_user

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue