No of records archived per execution of an archival rule

[Anonymous_guy]

Hi Servicenow enthusiast,

Just a bit curious about what factors decide the number of records archived per hourly execution of a archival rule. The documentation says that the entire archival job is divided into 10 batches with each batch archiving 100 records - This is the expectation if the following properties are untouched.
1) glide.db.archive.max_iterations - 10

2) glide.db.archive.batch_size - 100

The results were surprising when I run a simple archival rule on change request table with a condition "closed in this year". We had 5.9 k records to archive but it took only 6 batches to complete the archival - 5 batches archiving 1000 records each and the 6th one 900 in a SINGLE RUN!!.

In short, there was a multiplication factor or something that scaled the number of records archived per each batch execution. Here is how I was anticipating the system would work.
100 records X 10 batch = 1000 records in 1 hour
Total executions required = Total number of records/Number of records archived hourly=5900/1000 ~ 6
Hence, it takes 6 hours to complete the archival of all records.

Can somebody explain what is happening? Please correct me if the way I think is wrong.

[ThunderDev]

Hello, 

Did you ever find a solution to this or have any additional details? We are planning on using archival rules for data management.

[qprinsloo]

I was looking into this since these properties were not being honored in our instance. Figured I'd share here in case you've not found a solution. It seems glide.db.archive.batch_size and glide.db.archive.max_iterations have been deprecated since Paris per KB0995572. The number of workers are further controlled with glide.db.archiving.max_consumer_workers (see KB0998410). We don't have a glide.db.archive.chunk_size system property in our instance but seems that if this does not exist the system defaults to 1,000.

[Its_Azar]

Hi there @Anonymous_guy 

The batch size (100) and max iterations (10) properties are per worker thread, not a hard cap per archive run. During an archive execution, ServiceNow can spin up multiple workers and dynamically scale based on system load and available resources, so those 10×100 limits are applied per worker, not globally. That’s why you’re seeing ~1000 records per batch and ~5900 archived in a single run instead of spread across hours. In short, the platform optimizes archive throughput automatically, and the documentation values are guidelines—not strict ceilings for a single execution.