Failure Event Logging #2293

Closed
opened 2026-02-28 02:49:32 -05:00 by deekerman · 4 comments
Owner

Originally created by @DukazzCruz on GitHub (Jun 21, 2023).

⚠️ Please verify that this feature request has NOT been suggested before.

  • I checked and didn't find similar feature request

🏷️ Feature Request Type

UI Feature

🔖 Feature description

  1. Enable the addition of events that explain the causes of service disruptions.
  2. Capture relevant information for each failure event, such as problem description, start and end dates and times, duration, and any other pertinent details.
  3. Provide the ability to filter service failure events based on specific criteria, such as dates, duration, failure type, and more.
  4. Offer statistics and visualizations displaying the frequency of failure events, allowing users to identify patterns and trends.
  5. Empower users to make informed decisions based on the recorded failure events, including identifying recurring issues and planning improvements or infrastructure changes.

✔️ Solution

  1. Add a form or interface within the Uptime Kuma application that allows users to register service failure events.
  2. Include fields in the form for entering the problem description, start and end dates and times, duration, and any other relevant information.
  3. Store the failure events in a database associated with each monitored service.
  4. Implement filtering options in the user interface to enable users to search for failure events by date, duration, or other custom criteria.
  5. Utilize the stored data to generate statistics and visualizations illustrating the frequency of failure events, such as line charts or summary tables.
  6. Integrate these statistics and visualizations into the Uptime Kuma user interface, ensuring easy access for users to make data-driven decisions.
Originally created by @DukazzCruz on GitHub (Jun 21, 2023). ### ⚠️ Please verify that this feature request has NOT been suggested before. - [X] I checked and didn't find similar feature request ### 🏷️ Feature Request Type UI Feature ### 🔖 Feature description 1. Enable the addition of events that explain the causes of service disruptions. 2. Capture relevant information for each failure event, such as problem description, start and end dates and times, duration, and any other pertinent details. 3. Provide the ability to filter service failure events based on specific criteria, such as dates, duration, failure type, and more. 4. Offer statistics and visualizations displaying the frequency of failure events, allowing users to identify patterns and trends. 5. Empower users to make informed decisions based on the recorded failure events, including identifying recurring issues and planning improvements or infrastructure changes. ### ✔️ Solution 1. Add a form or interface within the Uptime Kuma application that allows users to register service failure events. 2. Include fields in the form for entering the problem description, start and end dates and times, duration, and any other relevant information. 3. Store the failure events in a database associated with each monitored service. 4. Implement filtering options in the user interface to enable users to search for failure events by date, duration, or other custom criteria. 5. Utilize the stored data to generate statistics and visualizations illustrating the frequency of failure events, such as line charts or summary tables. 6. Integrate these statistics and visualizations into the Uptime Kuma user interface, ensuring easy access for users to make data-driven decisions.
deekerman 2026-02-28 02:49:32 -05:00
Author
Owner

@CommanderStorm commented on GitHub (Jun 21, 2023):

@DukazzCruz Please limit yourself to one feature per feauture-request.
Also go into detail why this is nessesary.

Rationale: Like this, issue-deduplication is really hard (i would say impossible) and working on mulit-issue issues is more daunting than nessesary.

@CommanderStorm commented on GitHub (Jun 21, 2023): @DukazzCruz Please limit yourself to one feature per `feauture-request`. Also go into detail why this is nessesary. Rationale: Like this, issue-deduplication is really hard (i would say impossible) and working on mulit-issue issues is more daunting than nessesary.
Author
Owner

@DukazzCruz commented on GitHub (Jun 21, 2023):

@CommanderStorm:

I understand the functionality is needed because if events could be tagged by categories, it would be possible to track recurring events and take action to prevent them from recurring.

Recurring issues in physical and cloud server environments:
Hardware failures.
Infrastructure or network configuration problems.
Problems with the Internet service provider.
Insufficient scalability.
Security vulnerabilities.
Being able to track and monitor these events.

Monitoring the events that cause downtime can lead to decisions like switching providers, replacing devices, revising settings, and more.

@DukazzCruz commented on GitHub (Jun 21, 2023): @CommanderStorm: I understand the functionality is needed because if events could be tagged by categories, it would be possible to track recurring events and take action to prevent them from recurring. **Recurring issues in physical and cloud server environments:** Hardware failures. Infrastructure or network configuration problems. Problems with the Internet service provider. Insufficient scalability. Security vulnerabilities. Being able to track and monitor these events. Monitoring the events that cause downtime can lead to decisions like switching providers, replacing devices, revising settings, and more.
Author
Owner

@CommanderStorm commented on GitHub (Jun 21, 2023):

What you mean by event?

The problems I have currently is, that this is

  • a HUGE feature request. (this is not manageable, as it is currently presented).
    You are requesting
    • addition of a new event (what does this mean?) which a user can create
    • a view to search + filter events
    • statistics and visualizations (what do you mean?)
    • some unspecified way (ML?) identify recurring patterns
  • not particularly clear about what should be added where
  • How this would connect with other proposed systems (to be specific #1253)
@CommanderStorm commented on GitHub (Jun 21, 2023): What you mean by event? The problems I have currently is, that this is - a HUGE feature request. (this is not manageable, as it is currently presented). You are requesting - addition of a new event (what does this mean?) which a user can create - a view to search + filter events - statistics and visualizations (what do you mean?) - some unspecified way (ML?) identify recurring patterns - not particularly clear about what should be added where - How this would connect with other proposed systems (to be specific #1253)
Author
Owner

@DukazzCruz commented on GitHub (Jun 22, 2023):

This is what I mean. I just didn't know it by that name.

@DukazzCruz commented on GitHub (Jun 22, 2023): This is what I mean. I just didn't know it by that name.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/uptime-kuma#2293
No description provided.