---
title: "Is There an Example of Filtering Logs by Severity?"
url: "https://dm0bkdes5q7a2ls.productfruits.help/en/article/2dd0f5c0-e38a-437b-a4e3-42a5b6878025"
language: "en"
last_updated: "2026-04-29T21:34:55.902Z"
---

# Is There an Example of Filtering Logs by Severity?

Filtering by severity is one of the most effective ways to manage large log exports, as it enables you to prioritize critical errors over routine informational messages.

In the **Spirion Web API**, you can apply a severity filter using the `severity` query parameter.

### 1\. Severity Levels in Spirion

Spirion typically uses standard logging levels.

When filtering, you can specify one or more of the following:

-   `Critical` / `Fatal`: System-stopping events (e.g., service crashes).
-   `Error`: Action-stopping events (e.g., "Access Denied" on a target).
-   `Warning`: Non-fatal issues (e.g., "File skipped due to password protection").
-   `Info`: Routine operational updates (e.g., "Scan started," "Heartbeat successful").
-   `Debug`: Detailed technical data (only used for deep troubleshooting).

### 2\. Example API Request with Severity Filter

To retrieve only **Error** and **Critical** logs, your API request would look like this:

`GET` [`https://your-tenant.spirion.com/api/v1/agentlogs?severity=Error`](https://your-tenant.spirion.com/api/v1/agentlogs?severity=Error)`,Critical`

### 3\. Updated Python Script Example

Here is how you would modify the `params` dictionary in your export script to include a severity filter:

```py
def export_filtered_logs():
    # ... (setup code same as previous examples) ...
    # Define the severities you want to export
    # Common practice: Export Error and Critical for SIEM alerting
    target_severities = "Error,Critical"
    params = {
        "startDate": last_seen,
        "limit": 500,
        "severity": target_severities,  # Apply the filter here
        "sort": "timestamp_asc"
    }
    try:
        response = requests.get(endpoint, headers=headers, params=params)
        # ... (rest of the processing logic) ...
```

### 4\. Best Practices for Severity Filtering

-   **The "Alerting vs. Auditing" Split:**
-   -   **For SIEM Alerting:** Export only `Error` and `Critical`. This keeps your SOC focused on actionable issues.
    -   **For Compliance Auditing:** Export `Info`, `Warning`, `Error`, and `Critical`. This provides a complete "narrative" of system activity for auditors.
-   **Watch for "Warning" Trends:** While `Warning` logs don't stop a scan, a high volume of them (e.g., thousands of "File Skipped" messages) can indicate a configuration issue that is significantly reducing your scan coverage.
-   **Debug is for "On-Demand" Only:** Never leave a scheduled export script running with the `Debug` severity filter. The volume of data will likely overwhelm your storage and SIEM ingestion limits.
-   **Combine with Log Family:** For the most precise troubleshooting, combine severity with the log family. For example: `?severity=Error&logFamily=IFS` will show you only the errors related to result shipping.

### Summary

By adding the `severity` parameter to your API calls, you can transform a high-volume "firehose" of data into a targeted stream of actionable intelligence.

This ensures that your security team sees the critical "Access Denied" errors without being buried under thousands of "Heartbeat Successful" messages.