[Draft] Proposal: Monitoring Automation, Reporting, and Access Control Enhancements

[HowardPang1109]

❗ Important Announcements

This is a Draft Pull Request for discussion before finalizing the implementation.
This PR introduces multiple new features, so I would like to confirm whether the design direction and scope are acceptable before proceeding further.

---

📋 Overview

✅ What problem does this pull request address?

This contribution is motivated by several core limitations observed in real-world usage of Uptime Kuma:

1. Detection without Resolution

Knowing that a server is down does not bring it back up.
The current workflow is often:
Receive alert → Find a device → SSH into server → Manually restart service,
which is slow and inefficient, especially during off-hours.

2. Data Silos

Questions like “What was our uptime last month?” are difficult to answer because:

• There is no built-in portable report format (CSV / PDF)
• Stakeholders and clients lack formal uptime proof
• Historical data is not easily shareable

3. Unsafe Monitor Sharing

• Teams often share one single admin account
• All users have full control over all monitors
• There is no safe way to allow read-only access
  This causes serious security and operational risks in multi-user environments.

---

✅ What features or functionality does this pull request introduce?

This PR introduces three major new features:

---

🔧 1. Automatically Reboot When Service is Down

New fields added to the monitor editing page:

• SSH Host
• SSH Port
• SSH Username
• SSH Private Key
• Restart Script

When the monitored service goes offline, Uptime Kuma will:

1. Automatically connect to the target server via SSH
2. Execute the predefined restart script
3. Attempt to restore service without human intervention

This significantly reduces downtime and alert fatigue.

---

📄 2. Uptime Report Export (CSV / PDF)

A built-in reporting mechanism for a single monitor, including:

• Date (YYYY-MM-DD)
• Daily Uptime (%)
• Downtime Events (count)
• Total Downtime (minutes)
• Longest Outage (minutes)
• Mean Response Time (ms)

Features:

• Export Format: CSV / PDF
• Time Scope: Customizable (default 30 days, max 30 days)

This enables:

• Formal SLA reporting
• Historical performance review
• Client-facing uptime proof

---

👥 3. Role-Based Monitor Access Control

A fine-grained permission management mechanism allowing:

• Assigning specific users to specific monitors
• Role types:
  • Editor → Can modify monitor
  • Viewer → Read-only access
• Unauthorized users:
  • Cannot edit or view protected monitors

This allows:

• Secure multi-user collaboration
• No need to share admin credentials
• Clear responsibility separation in teams

---

🔗 Related Issues

• Relates to: N/A
• Resolves: N/A

---

🛠️ Type of change

• ✨ New feature (non-breaking)
• 🎨 User Interface (UI) updates
• 🐛 Bugfix
• ⚠️ Breaking change
• 📄 New Documentation
• 📄 Documentation Update
• 🔧 Other:

---

📄 Checklist

• 🔍 My code adheres to the style guidelines of this project.
• 🦿 I have indicated where I used an LLM for assistance.
• ✅ I ran ESLint and related linters on modified files.
• 🛠️ I have reviewed and tested my code.
• 📝 I have commented my code where necessary.
• ⚠️ My changes generate no new warnings.
• 🤖 Automated tests added (not included yet).
• 📄 Documentation updates will be added after design confirmation.
• 🔒 I have considered potential security impacts.
• 🧰 Dependency updates (not applicable).
• 📚 I have read and understood the Pull Request guidelines.

---

📷 Screenshots or Visual Changes

Screenshots will be provided after maintainer confirmation of feature scope.

Feature	Before	After
Auto Reboot	N/A	To be added
Report Export	N/A	To be added
Monitor Access Control	N/A	To be added

---

🤖 LLM Usage Disclosure

Parts of the **PR description, feature planning discussion and implementation (system design, coding, testing) were assisted by LLM, and final decisions were fully reviewed and implemented by me and my team.

[louislam]

1. Automatically Reboot

Do not accept.

There are too many deployment methods in the world. Restarting the server via ssh is just one of them. People could use Docker, Podman, AWS etc.

It has a lot to think. As least it should be an one-to-many relation. Adding to the monitor table directly does not seem to be correct.

However, if you need this, you can do it via Webhook Notification outside of Uptime Kuma.

2. Role

Do not accept.
Conflict with #6276

3. Uptime Report Export

Maybe. As long as it is easy to be maintained.

Also this pr is heavily LLM-ed. We don't accept LLM on such size of PR. Feel free to open a new pull request for Uptime Report Export, if you agree it, otherwise, let's don't waste each others' time.