Add "Response" column to Heartbeat table to make response data available for notifications (e.g. SMTP)

[kevgoehl]

📑 I have found these related issues/pull requests

I searched for related issues and PRs mentioning keywords such as “response body”, “heartbeatJSON”, “email template”, “notification body”, and “json-query” but could not find any that directly address adding a response column to the heartbeat table.

There are discussions about exposing more heartbeat data in notifications, but none seem to focus on persisting the response for HTTP Requests via Axios.

Therefore, this appears to be a new enhancement proposal.

🏷️ Feature Request Type

Change to existing monitor

🔖 Feature description

Currently, HTTP(s) monitors in Uptime Kuma can't access the response data of the monitor heartbeat.

As a result, notifications (SMTP, Discord, etc.) can't include the actual response data, even though it’s technically available at runtime.

Adding a dedicated response (or responseBody) field to the heartbeat table would allow templates and APIs to access the most recent response safely and consistently.

✔️ Solution

• Extend the heartbeat model and table with a new column (e.g. response or responseBody).
• Populate this column with the monitor’s last response when:
  • The monitor type supports responses
• Expose the new field in heartbeatJSON and make it accessible to notification templates (Liquid).
• Optionally add a UI toggle, e.g. “Store response for notifications,” to control database growth.

This change would make {{ heartbeatJSON.response }} usable inside notifications like SMTP or webhooks.

❓ Alternatives

No response

📝 Additional Context

If this feature request is accepted, I would be able to start implementing it and submit a pull request for review.

[CommanderStorm]

Seems reasonable