llms.txt
Search Documentation
Search through all documentation pages
v4.x

v4.0.0 Changelog

See what's new in Kener v4.0.0, including new features, improvements, and bug fixes

Kener v4.0.0 is a major release with architecture, API, and data-model changes. This release adds new platform capabilities (pages, recurring maintenance, customizable templates, improved subscriptions), and introduces several migration requirements for existing v3 deployments.

Breaking changes

Redis is now required for full functionality

Redis is now a core runtime dependency for queues/background workflows (alerts, scheduling, email fan-out, docs indexing updates, and related async operations).

If you are upgrading from v3, make sure REDIS_URL is configured in your environment.

Heartbeat endpoint changed

Heartbeat monitor URL changed from v3 to v4:

  • v3: /api/heartbeat/{tag}:{secret}
  • v4: /ext/heartbeat/{tag}:{secret}

Both GET and POST remain supported, but old integrations must update the path.

Subscription system redesigned

The subscription model and storage were redesigned in v4.

Deprecated tables:

  • subscription_triggers
  • subscriptions
  • subscribers

The invitations table is also deprecated as part of the v4 redesign and user-flow updates.

API contract changed (v3 → v4)

Comparing static/api-references/v3.json and static/api-references/v4.json:

  • 36 endpoints/methods added
  • 16 endpoints/methods removed

Notable direction of change:

  • New resource namespaces under /api/v4/*
  • Added first-class resources for:
    • incidents + incident comments
    • maintenances + maintenance events
    • monitors + monitoring data edits
    • pages
    • site config keys
  • Legacy v3 routes such as /api/incident/*, /api/monitor*, /api/status were replaced by v4 resource-oriented routes.

Data model and migration notes

New page model and subpath support

v4 introduces page-scoped status views and monitor mapping:

  • pages
  • pages_monitors

You can now publish multiple status pages/subpaths from one instance and control monitor visibility per page.

Categories and monitor ordering moved to pages

In v4, monitor grouping/display should be managed through Pages.

  • Add monitors to a page and they will be shown in that page order.
  • The monitor order on a page is the order users see on the status page.

Recurring maintenance scheduling

v4 adds RRULE-based maintenance scheduling with dedicated tables:

  • maintenances
  • maintenance_monitors
  • maintenances_events

This enables one-time and recurring maintenance windows with generated event instances.

Monitor maintenance impact and status override

Maintenance now supports per-monitor impact/status behavior (for example MAINTENANCE override while events are ongoing), improving incident communication during planned work.

Monitoring data enhancements

Monitoring data now includes richer operational context, including support for error_message fields and improved data inspection/update workflows in v4 APIs and dashboard tooling.

New and improved capabilities

User subscriptions and admin workflows

  • Subscription UX has been redesigned
  • Better incidents/maintenances preference flows
  • Admin can add/manage subscribers directly from dashboard
  • Subscription notifications now align with v4 incident and maintenance lifecycle events

Customizable email templates

Built-in email templates can now be managed and customized from the dashboard (Manage → Templates), including subscription-related templates.

Announcement banner

v4 supports site-wide announcement banners with richer controls (message, type, dismiss behavior, optional CTA).

Embed and event visibility improvements

  • Live events embed experiences were expanded
  • Better event surfacing for ongoing incidents/maintenances
  • Improved sharing/embedding workflows for status communications

Uptime calculation flexibility

Uptime behavior is more configurable in v4, including formula-level flexibility and maintenance-aware behavior.

Rendering and dashboard UX upgrades

v4 includes broader frontend/runtime improvements, including more client-driven data interactions for monitor and operational views, with improved responsiveness and control.

Known migration issues (v3 → v4)

Community-reported issues when upgrading from v3 to v4. Review these before migrating.

Uploaded files and custom fonts return 404

v3 served static files (images, fonts) from the /uploads/ directory. v4 stores images in the database and serves them from /assets/images/[id].

After upgrading, any URL referencing /uploads/... will return 404. This affects:

  • Custom font files (.woff2, .woff, .ttf) referenced in Custom CSS
  • Any image previously uploaded via the v3 dashboard

Fix: Re-upload site images (logo, favicon, etc.) through the v4 dashboard (Manage → Site). For custom fonts, host them externally (CDN or self-hosted URL) and update your Custom CSS @font-face src URLs accordingly.

Subscriptions and subscribers are not migrated

The subscription system was fully redesigned in v4 with new tables (subscriber_users, subscriber_methods, user_subscriptions_v2). Data from v3 tables (subscribers, subscriptions, subscription_triggers) is not automatically migrated.

Fix: After upgrading, re-configure subscription settings in the v4 dashboard. Existing subscribers will need to re-subscribe.

Monitor timeout type error

Monitors migrated from v3 may store the timeout value as a string (e.g. "30000") instead of a number. This causes a runtime error:

"msecs" argument must be of type number. Received type string ('30000')

Fix: Open each affected monitor in the v4 dashboard, verify the timeout value, and save. Re-saving converts the value to the correct numeric type.

Monitors not visible on status pages

v4 introduced a Pages model where monitors must be explicitly assigned to a page before they appear on any status page. After migration, existing monitors will not be visible until assigned.

Fix: Go to Manage → Pages, create or edit a page, and assign your monitors to it.

Site images (logo, favicon) need re-upload

Site branding images (logo, favicon) uploaded in v3 are stored as file paths pointing to /uploads/. v4 expects these as database-stored images.

Fix: Go to Manage → Site and re-upload your logo and favicon.

Upgrade checklist from v3

Before promoting v4 to production:

  1. Configure Redis (REDIS_URL).
  2. Update all heartbeat callers to /ext/heartbeat/{tag}:{secret}.
  3. Re-upload site images (logo, favicon) via Manage → Site — v3 /uploads/ paths no longer work.
  4. Assign monitors to pages via Manage → Pages — monitors are not visible until assigned.
  5. Open and re-save any monitors that used a custom timeout to fix string-to-number type issues.
  6. Re-configure subscriptions — v3 subscriber data is not migrated to the new v4 system.
  7. If you used custom fonts via /uploads/, host them externally and update Custom CSS @font-face URLs.
  8. Audit integrations/scripts for removed v3 API routes.
  9. Regenerate or re-import API clients from static/api-references/v4.json.
  10. Validate custom domain + ORIGIN and auth form behavior in production.

See also