louislam/uptime-kuma · error · Error

Notification type is not supported

Error message

Notification type is not supported

What it means

Thrown by Notification.send when notification.type does not correspond to any registered provider name in the providerList. The providerList is keyed by each provider's `name` field during init(); an unknown type means the value was never registered (removed provider, corrupted row, or external caller passing an ad-hoc type).

Source

Thrown at server/notification.js:254

            }
            this.providerList[item.name] = item;
        }
    }

    /**
     * Send a notification
     * @param {BeanModel} notification Notification to send
     * @param {string} msg General Message
     * @param {object} monitorJSON Monitor details (For Up/Down only)
     * @param {object} heartbeatJSON Heartbeat details (For Up/Down only)
     * @returns {Promise<string>} Successful msg
     * @throws Error with fail msg
     */
    static async send(notification, msg, monitorJSON = null, heartbeatJSON = null) {
        if (this.providerList[notification.type]) {
            return this.providerList[notification.type].send(notification, msg, monitorJSON, heartbeatJSON);
        } else {
            throw new Error("Notification type is not supported");
        }
    }

    /**
     * Save a notification
     * @param {object} notification Notification to save
     * @param {?number} notificationID ID of notification to update
     * @param {number} userID ID of user who adds notification
     * @returns {Promise<Bean>} Notification that was saved
     */
    static async save(notification, notificationID, userID) {
        let bean;

        if (notificationID) {
            bean = await R.findOne("notification", " id = ? AND user_id = ? ", [notificationID, userID]);

            if (!bean) {
                throw new Error("notification not found");

View on GitHub (pinned to 6b5ea01557)

Solutions

  1. Check the notification row's type value in the DB and compare it against the registered provider names (see notification.js:123-228).
  2. If the provider was removed in an upgrade, delete the orphaned notification or migrate it to a supported type.
  3. If adding a custom provider, register it in the list inside Notification.init() with a unique name.
  4. Ensure Notification.init() runs at startup before any send() call.
Defensive patterns

Strategy: validation

Validate before calling

// Ensure init() ran and the requested type is registered before dispatch
function isRegisteredProvider(type, providerList) {
    return Object.prototype.hasOwnProperty.call(providerList, type);
}
if (!isRegisteredProvider(notification.type, Notification.providerList)) {
    throw new Error(`Notification type '${notification.type}' is not supported`);
}

Type guard

/** Narrows to a type string backed by a registered provider. */
function isSupportedNotificationType(type, providerList) {
    return typeof type === "string" && Object.prototype.hasOwnProperty.call(providerList, type);
}

Try / catch

if (!isSupportedNotificationType(notification.type, this.providerList)) {
    throw new Error(`Notification type '${notification.type}' is not supported`);
}
return this.providerList[notification.type].send(notification, msg, monitorJSON, heartbeatJSON);

Prevention

When it happens

Trigger: A notification bean in the DB has a type string that no longer matches any provider (e.g. provider was renamed/removed in a newer Uptime Kuma version), or an API caller posts a notification with a fabricated type. Also possible if Notification.init() was not called before send().

Common situations: Upgrade removed a provider whose notifications still exist in the DB, manual DB edits changing the type, or a custom provider not added to the list in notification.js:123.

Related errors


AI-assisted analysis of louislam/uptime-kuma@6b5ea01557 (2026-08-12). Data as JSON: /api/errors/c45c1e69da320428. Report an issue: GitHub.