IT System Administrator at a tech vendor with 201-500 employees
Real User
Top 5
May 22, 2026
One area that needs improvement is performance during heavy log ingestion workloads. In our environment, there are situations where Falcon LogScale experiences delays while forwarding large amounts of data to CrowdStrike XDR. During peak usage, ingestion can slow down and logs may take additional time to appear on the XDR dashboard. Improved scalability, better worker management, and faster real-time ingestion handling would enhance the overall experience, especially for environments processing large log volumes continuously.
In the future, I hope Falcon LogScale can include more AI-driven threat detection, advanced anomaly analytics, automated response workflow, deeper cloud security monitoring, and UEBA features.
There should be some tagging in Falcon LogScale. As I am tagging the endpoints for different domains and locations, the firewall should be tagged as well so that in the detections I can get the firewall name or the source name and source host name from which I am getting the information. If I have multiple sources in the correlation detections, I need those details of the multiple sources. It should be prescribed and very effective to understand Level 1s and share those details with the concerned team so that they can fastly proceed with the triage on the detection and take action. The price is, without question, very costly for any organization that has more than 1,000 or 2,000 users. It is still costly because for more than 10,000 users, one can go with Falcon LogScale, but for less than 10,000 users and more than 2,000 users, it is very costly. The product is scalable, but the support needs to be updated. The support team should be fast because there is a very slow response. Support should be faster because if a ticket has been raised, it should not go to the support engineers who are sitting abroad or outside India. It should be segregated and sent to the IST support team who is managing support in India. Once anybody gets into it and answers it, if they are not available in that particular shift according to IST, that can delay the response on the case and might have a bigger impact on the environment. The support team is pretty slow. They should improve first-level support quality. They usually avoid coming on a remote session to understand the exact scenario because there are issues related to different scenarios. Writing a few things on the case would not make them understand the exact situation I am facing. They should come on a remote session at least once on an immediate basis so that I can make them understand things, which will help in providing a resolution as soon as possible.
CrowdStrike is ahead of the game. If I may say anything about Falcon LogScale to improve the services, I would talk about the way you develop parsers. The documentation should be more straightforward. It is not easy to quickly find the documentation, especially if you are using CrowdStrike. Most customers use Falcon LogScale because of CrowdStrike. The documentation of Falcon LogScale is not on the CrowdStrike portal just like the rest of Falcon documentation. I usually find that the main Falcon LogScale documentation is found on the Falcon LogScale website itself. I think there should be a link or direct documentation within the CrowdStrike pages. It is not necessarily a fault. If you find where the documentation resides, you can trace it to what they are doing. However, for the ease of use for Falcon administrators, the same documentation on the Falcon LogScale portal should be on the CrowdStrike dashboard.
I have not worked on that particular part, but regarding improvement, KQL seems to be quite complicated and we have to brush up on that if we want to become an expert on it. KQL is a bit challenging for us. When we talk about Microsoft, KQL is simpler when compared to SQL. However, SQL is faster and quite efficient, but the language is a bit tough, maybe because it is new. I have just been working with it for the past two years. If I have more exposure in the coming years, it will become an easier option for me. KQL should be simplified, which would be a better thing. The documentation should not only be private but should be made public. Though we are partners and have access to those documents, sometimes I conduct testing on my own and have to log into a partner account or customer account to access those documents. That has to be improved. SQL has to be improved as well. When it comes to the overall Falcon LogScale console, it could be easier if it were made more attractive. For example, if something is shown on the dashboard with simplified icons and text, it would be a great option if there were some colors or larger icons. One drawback I have seen with Falcon LogScale is that there is something that cannot be customized. There is an account detection that seems to be a systematic account, and if we want to change it from a systematic account to a user account when it is detecting a system account, that seems to be a problem for us.
The integration could improve. Easy parser writing should be an option to ingest log in a human-readable format for unsupported devices. For visibility perspective, the dashboard should be more user-friendly. It should visualize what is happening in the complete ingestion, showing how many log sources there are, data volumes, and use cases or correlation rules triggered based on AI and ML analytics.
Falcon LogScale is a modern log management tool that offers robust features for organizations seeking efficient log analysis. It provides high-speed log ingestion and query capabilities, enabling detailed insights into system performance and security events.
Falcon LogScale provides an efficient way for IT teams to handle massive volumes of log data. Its architecture supports rapid ingestion and real-time querying, making it ideal for security and operational analytics. With customizable...
One area that needs improvement is performance during heavy log ingestion workloads. In our environment, there are situations where Falcon LogScale experiences delays while forwarding large amounts of data to CrowdStrike XDR. During peak usage, ingestion can slow down and logs may take additional time to appear on the XDR dashboard. Improved scalability, better worker management, and faster real-time ingestion handling would enhance the overall experience, especially for environments processing large log volumes continuously.
In the future, I hope Falcon LogScale can include more AI-driven threat detection, advanced anomaly analytics, automated response workflow, deeper cloud security monitoring, and UEBA features.
There should be some tagging in Falcon LogScale. As I am tagging the endpoints for different domains and locations, the firewall should be tagged as well so that in the detections I can get the firewall name or the source name and source host name from which I am getting the information. If I have multiple sources in the correlation detections, I need those details of the multiple sources. It should be prescribed and very effective to understand Level 1s and share those details with the concerned team so that they can fastly proceed with the triage on the detection and take action. The price is, without question, very costly for any organization that has more than 1,000 or 2,000 users. It is still costly because for more than 10,000 users, one can go with Falcon LogScale, but for less than 10,000 users and more than 2,000 users, it is very costly. The product is scalable, but the support needs to be updated. The support team should be fast because there is a very slow response. Support should be faster because if a ticket has been raised, it should not go to the support engineers who are sitting abroad or outside India. It should be segregated and sent to the IST support team who is managing support in India. Once anybody gets into it and answers it, if they are not available in that particular shift according to IST, that can delay the response on the case and might have a bigger impact on the environment. The support team is pretty slow. They should improve first-level support quality. They usually avoid coming on a remote session to understand the exact scenario because there are issues related to different scenarios. Writing a few things on the case would not make them understand the exact situation I am facing. They should come on a remote session at least once on an immediate basis so that I can make them understand things, which will help in providing a resolution as soon as possible.
CrowdStrike is ahead of the game. If I may say anything about Falcon LogScale to improve the services, I would talk about the way you develop parsers. The documentation should be more straightforward. It is not easy to quickly find the documentation, especially if you are using CrowdStrike. Most customers use Falcon LogScale because of CrowdStrike. The documentation of Falcon LogScale is not on the CrowdStrike portal just like the rest of Falcon documentation. I usually find that the main Falcon LogScale documentation is found on the Falcon LogScale website itself. I think there should be a link or direct documentation within the CrowdStrike pages. It is not necessarily a fault. If you find where the documentation resides, you can trace it to what they are doing. However, for the ease of use for Falcon administrators, the same documentation on the Falcon LogScale portal should be on the CrowdStrike dashboard.
I have not worked on that particular part, but regarding improvement, KQL seems to be quite complicated and we have to brush up on that if we want to become an expert on it. KQL is a bit challenging for us. When we talk about Microsoft, KQL is simpler when compared to SQL. However, SQL is faster and quite efficient, but the language is a bit tough, maybe because it is new. I have just been working with it for the past two years. If I have more exposure in the coming years, it will become an easier option for me. KQL should be simplified, which would be a better thing. The documentation should not only be private but should be made public. Though we are partners and have access to those documents, sometimes I conduct testing on my own and have to log into a partner account or customer account to access those documents. That has to be improved. SQL has to be improved as well. When it comes to the overall Falcon LogScale console, it could be easier if it were made more attractive. For example, if something is shown on the dashboard with simplified icons and text, it would be a great option if there were some colors or larger icons. One drawback I have seen with Falcon LogScale is that there is something that cannot be customized. There is an account detection that seems to be a systematic account, and if we want to change it from a systematic account to a user account when it is detecting a system account, that seems to be a problem for us.
I do not see any improvements needed for Falcon LogScale at this time.
The integration could improve. Easy parser writing should be an option to ingest log in a human-readable format for unsupported devices. For visibility perspective, the dashboard should be more user-friendly. It should visualize what is happening in the complete ingestion, showing how many log sources there are, data volumes, and use cases or correlation rules triggered based on AI and ML analytics.
So far, there are no features in need of improvement. The price could be lower.
There are some overlapping features found in multiple tools.