In my organization, particularly in Ericsson's telecom BSS domain, the primary use case of Coralogix is centralized log management and real-time monitoring of telecom applications, such as the BSS software products and infrastructure. We have multiple SDP and AIR components in our telecom stack, including application servers, network elements, microservices, and APIs. Coralogix acts as a single platform where all logs are aggregated, which makes troubleshooting much faster compared to using different systems. The platform also helps with monitoring live traffic and system behavior. We have configured alerts for critical scenarios such as service downtime, API failures, error rates, and spikes. Using Coralogix has significantly improved the efficiency and structure of my daily work, especially in monitoring and troubleshooting. Previously, we relied on manual checks and customer complaints to identify different issues. Now, with real-time alerts in Coralogix, we get notified immediately when something goes wrong, such as API failures or abnormal error spikes. The approach has shifted from reactive troubleshooting to proactive monitoring. Previously, we had to log into multiple servers and manually check logs, which was time-consuming. Now, everything is centralized in Coralogix, and with powerful search and filtering, we can quickly pinpoint issues within minutes instead of hours. One recent incident involved a production issue where one of our SDP application services started showing intermittent API failures during peak traffic hours. Subscribers in Singapore were experiencing delayed responses, and some transactions were failing. Initially, it was difficult to identify the root cause because multiple microservices and backend systems were involved. Using Coralogix, we were able to quickly narrow down the issue through real-time log monitoring, centralized log correlation, advanced filtering and search, and alerting dashboards. We observed through Coralogix dashboards that error rates suddenly increased for a particular service after a deployment. By filtering logs based on transaction IDs and timestamps, we traced the issue to a backend service timeout caused by a misconfigured connection pool. The biggest advantage was that we did not need to manually log into multiple servers to investigate. Everything was visible from a single platform, which saved considerable troubleshooting time. Because of Coralogix alerts, the operations team was informed immediately, and we resolved the issue much faster than our general earlier processes, significantly reducing troubleshooting time and providing faster root cause identification.
DevOps & FinOps Engineer at a tech services company with 501-1,000 employees
MSP
Top 20
Apr 29, 2026
My main use case for Coralogix was that we transferred from DataDog because DataDog was expensive at the time, and we wanted something more cost-effective. The VP of R&D thought Coralogix would be a great solution to replace DataDog. We used it for observability, logs of services, traceability of services that reach from certain endpoints, and everything related to metrics. We also used it in the queries and their Grafana managed dashboards, so we could view all of our Kubernetes workloads, whether it was RabbitMQ brokers panels or Kafka. We integrated it with so many things. A specific example of how I used Coralogix in my daily work is that I opened Coralogix when developers had issues with their services, such as having 500 error codes or 400 error codes. We would observe the logs and see the logs that were transferred to Coralogix for the service, which were enriched with the data of the name of their service, the tags, and many other things that we did with the help of OpenTelemetry agents that transferred the data to Coralogix. We also sent log groups of specific RDSs that we managed via AWS, so it was better for metrics gathering and logs observability.
My main use case for Coralogix is to see logs. I initially used it for a logging system, so every user can see the logs. Logs are published via AWS to Coralogix, and I set up log-related alerts and observability to analyze metrics using dashboards. These are the major areas. When I debug our system, I filter based on the service names that I have already published from the ingress logs. I have also published some MDC tags that are visible, so I filter based on the tags or a particular message or trace ID. This is how I do log analysis. For setting up alerts, I use an alerting dashboard where I set the queries for specific logs. If a log or log-related query appears more than five times within a specific timeframe, such as the last five minutes or one hour, I can raise an alert for errors like 4xx errors.
My main use case with Coralogix has been to troubleshoot, narrow down the problem, understand the logs, and identify errors. For troubleshooting or analyzing logs, we usually employ two methods. The first method is sorting by time, where we trigger an action and see in real-time if it appears or not. The second one involves using services. We know that some actions will trigger specific services, so we filter it by services and, after triggering it, we check if there is an error or a log trace to see in which service the error is happening.
My main use case for Coralogix is that it's a great application performance monitoring tool. I use it to take care of the services through it. I set up the dashboard here for all the types of services and routes to check whenever we receive any kind of error response, time request, or issues.
Software Engineer at a computer software company with 201-500 employees
Real User
Top 20
Dec 4, 2025
My main use case for Coralogix is logging and log monitoring. I use Coralogix for log analytics, as whatever logs are going into it are analyzed for any issues that arise.
Coralogix serves as my main observability tool, similar to Kibana and Datadog. It provides observability and monitoring of all troubleshooting for all infrastructures and systems in real time. I can analyze and perform root cause analysis in real time, and it helps with logs and real-time access to logs, whether they are structured or unstructured types. It covers all databases, applications, and application-specific logs such as traces. I can use that alongside all metrics, security data, and dashboards. There are certain dashboards available, so most of the use cases we have been using this. On a day-to-day basis, the use cases for Coralogix include integrating dashboards, integrating Slack and Teams notifications for all opportunities. Alongside, I get the logs in real time and can store whatever is necessary. I can archive certain logs as well, and it has security information and event management, the SIEM capabilities. It can integrate with Prometheus and Grafana, the open-source technologies available, and the open telemetry technologies that are available in the market today. A specific scenario where Coralogix helped me is when we log into services and systems, and most of the time certain nodes in the cluster, one of the nodes gets down. When one of the nodes is down, I need to log into certain logs or check the services to determine which services are down, and based upon the services, I need to go to the specific log section, take out the logs and see. During the timestamp, I have to analyze the logs along with the timestamp and see what is happening. I need to see the post-event analysis and post-event logs to determine why the server or machine is down, what the cause is, and any specific issues. Coralogix helps with all real-time logs, pattern, and real-time analysis, providing an overview of what is happening. Instead of directly logging into the server, I just go to the Coralogix dashboard and see the logs and the machine, and I perform my RCA, whether I am the system engineer or the system administrator.
We are building a reconciliation system where we handle the in and out of transactions daily. We maintain a record to verify if transactions came at the expected time and match them with the bank statement. We also deal with Kafka and pod failures, high Kafka lag, and have integrated Grafana with Coralogix to monitor Kafka lag on each topic.
DevOps & Cloud Lead at a transportation company with 51-200 employees
Real User
Nov 29, 2022
Our primary use case for the solution is pushing logs so we can find the log there or provide it as a self-service to the developers, and developers can see logs and what's going on. So mostly the standard debugging use case.
VP of Engineering at a financial services firm with 51-200 employees
Real User
Jul 18, 2022
It's a login solution. We have a bunch of applications running in our cloud and all the logs with stalled applications and rates. We put those logs in Coralogix. Then we analyze those logs for various things, including alerts, data analysis, investigations, et cetera.
Coralogix provides a robust platform for real-time logging and analysis, offering seamless integration with cloud services and DevOps tools to enhance visibility and error detection.Coralogix is recognized for facilitating efficient log management through intuitive drill-down capabilities and AI-powered anomaly detection. Its platform supports smooth integration with multiple cloud providers and DevOps tools, focusing on ease of use and effective data migration. Users benefit from rich...
In my organization, particularly in Ericsson's telecom BSS domain, the primary use case of Coralogix is centralized log management and real-time monitoring of telecom applications, such as the BSS software products and infrastructure. We have multiple SDP and AIR components in our telecom stack, including application servers, network elements, microservices, and APIs. Coralogix acts as a single platform where all logs are aggregated, which makes troubleshooting much faster compared to using different systems. The platform also helps with monitoring live traffic and system behavior. We have configured alerts for critical scenarios such as service downtime, API failures, error rates, and spikes. Using Coralogix has significantly improved the efficiency and structure of my daily work, especially in monitoring and troubleshooting. Previously, we relied on manual checks and customer complaints to identify different issues. Now, with real-time alerts in Coralogix, we get notified immediately when something goes wrong, such as API failures or abnormal error spikes. The approach has shifted from reactive troubleshooting to proactive monitoring. Previously, we had to log into multiple servers and manually check logs, which was time-consuming. Now, everything is centralized in Coralogix, and with powerful search and filtering, we can quickly pinpoint issues within minutes instead of hours. One recent incident involved a production issue where one of our SDP application services started showing intermittent API failures during peak traffic hours. Subscribers in Singapore were experiencing delayed responses, and some transactions were failing. Initially, it was difficult to identify the root cause because multiple microservices and backend systems were involved. Using Coralogix, we were able to quickly narrow down the issue through real-time log monitoring, centralized log correlation, advanced filtering and search, and alerting dashboards. We observed through Coralogix dashboards that error rates suddenly increased for a particular service after a deployment. By filtering logs based on transaction IDs and timestamps, we traced the issue to a backend service timeout caused by a misconfigured connection pool. The biggest advantage was that we did not need to manually log into multiple servers to investigate. Everything was visible from a single platform, which saved considerable troubleshooting time. Because of Coralogix alerts, the operations team was informed immediately, and we resolved the issue much faster than our general earlier processes, significantly reducing troubleshooting time and providing faster root cause identification.
My main use case for Coralogix was that we transferred from DataDog because DataDog was expensive at the time, and we wanted something more cost-effective. The VP of R&D thought Coralogix would be a great solution to replace DataDog. We used it for observability, logs of services, traceability of services that reach from certain endpoints, and everything related to metrics. We also used it in the queries and their Grafana managed dashboards, so we could view all of our Kubernetes workloads, whether it was RabbitMQ brokers panels or Kafka. We integrated it with so many things. A specific example of how I used Coralogix in my daily work is that I opened Coralogix when developers had issues with their services, such as having 500 error codes or 400 error codes. We would observe the logs and see the logs that were transferred to Coralogix for the service, which were enriched with the data of the name of their service, the tags, and many other things that we did with the help of OpenTelemetry agents that transferred the data to Coralogix. We also sent log groups of specific RDSs that we managed via AWS, so it was better for metrics gathering and logs observability.
My main use case for Coralogix is to see logs. I initially used it for a logging system, so every user can see the logs. Logs are published via AWS to Coralogix, and I set up log-related alerts and observability to analyze metrics using dashboards. These are the major areas. When I debug our system, I filter based on the service names that I have already published from the ingress logs. I have also published some MDC tags that are visible, so I filter based on the tags or a particular message or trace ID. This is how I do log analysis. For setting up alerts, I use an alerting dashboard where I set the queries for specific logs. If a log or log-related query appears more than five times within a specific timeframe, such as the last five minutes or one hour, I can raise an alert for errors like 4xx errors.
My main use case with Coralogix has been to troubleshoot, narrow down the problem, understand the logs, and identify errors. For troubleshooting or analyzing logs, we usually employ two methods. The first method is sorting by time, where we trigger an action and see in real-time if it appears or not. The second one involves using services. We know that some actions will trigger specific services, so we filter it by services and, after triggering it, we check if there is an error or a log trace to see in which service the error is happening.
My main use case for Coralogix is that it's a great application performance monitoring tool. I use it to take care of the services through it. I set up the dashboard here for all the types of services and routes to check whenever we receive any kind of error response, time request, or issues.
My main use case for Coralogix is logging and log monitoring. I use Coralogix for log analytics, as whatever logs are going into it are analyzed for any issues that arise.
Coralogix serves as my main observability tool, similar to Kibana and Datadog. It provides observability and monitoring of all troubleshooting for all infrastructures and systems in real time. I can analyze and perform root cause analysis in real time, and it helps with logs and real-time access to logs, whether they are structured or unstructured types. It covers all databases, applications, and application-specific logs such as traces. I can use that alongside all metrics, security data, and dashboards. There are certain dashboards available, so most of the use cases we have been using this. On a day-to-day basis, the use cases for Coralogix include integrating dashboards, integrating Slack and Teams notifications for all opportunities. Alongside, I get the logs in real time and can store whatever is necessary. I can archive certain logs as well, and it has security information and event management, the SIEM capabilities. It can integrate with Prometheus and Grafana, the open-source technologies available, and the open telemetry technologies that are available in the market today. A specific scenario where Coralogix helped me is when we log into services and systems, and most of the time certain nodes in the cluster, one of the nodes gets down. When one of the nodes is down, I need to log into certain logs or check the services to determine which services are down, and based upon the services, I need to go to the specific log section, take out the logs and see. During the timestamp, I have to analyze the logs along with the timestamp and see what is happening. I need to see the post-event analysis and post-event logs to determine why the server or machine is down, what the cause is, and any specific issues. Coralogix helps with all real-time logs, pattern, and real-time analysis, providing an overview of what is happening. Instead of directly logging into the server, I just go to the Coralogix dashboard and see the logs and the machine, and I perform my RCA, whether I am the system engineer or the system administrator.
The use case for my organization is that we need a vendor to host our metrics.
Our company's use case for Coralogix is to protect our customers and support some attacks because here in Brazil, EFT is responsible for that.
We are building a reconciliation system where we handle the in and out of transactions daily. We maintain a record to verify if transactions came at the expected time and match them with the bank statement. We also deal with Kafka and pod failures, high Kafka lag, and have integrated Grafana with Coralogix to monitor Kafka lag on each topic.
We use Coralogix to analyze our log metrics. We were looking for an enhanced tool to help us secure our real-time data.
Our primary use case for the solution is pushing logs so we can find the log there or provide it as a self-service to the developers, and developers can see logs and what's going on. So mostly the standard debugging use case.
We primarily use it for metrics and reports.
It's a login solution. We have a bunch of applications running in our cloud and all the logs with stalled applications and rates. We put those logs in Coralogix. Then we analyze those logs for various things, including alerts, data analysis, investigations, et cetera.
The solution is mostly used for basic log monitoring, the sync of logs, log analyzing, log collection, et cetera.