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_triggerssubscriptionssubscribers
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 commentsmaintenances+ maintenance eventsmonitors+ monitoring data editspagessiteconfig keys
- Legacy v3 routes such as
/api/incident/*,/api/monitor*,/api/statuswere 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:
pagespages_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:
maintenancesmaintenance_monitorsmaintenances_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:
- Configure Redis (
REDIS_URL). - Update all heartbeat callers to
/ext/heartbeat/{tag}:{secret}. - Re-upload site images (logo, favicon) via Manage → Site — v3
/uploads/paths no longer work. - Assign monitors to pages via Manage → Pages — monitors are not visible until assigned.
- Open and re-save any monitors that used a custom timeout to fix string-to-number type issues.
- Re-configure subscriptions — v3 subscriber data is not migrated to the new v4 system.
- If you used custom fonts via
/uploads/, host them externally and update Custom CSS@font-faceURLs. - Audit integrations/scripts for removed v3 API routes.
- Regenerate or re-import API clients from
static/api-references/v4.json. - Validate custom domain +
ORIGINand auth form behavior in production.