rajnandan1/kener v4.0.1

Kener v4 release

on GitHub

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 {#breaking-changes}

Redis is now required for full functionality {#redis-required}

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-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 {#subscriptions-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) {#api-contract-changed}

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 {#data-model-and-migration-notes}

New page model and subpath support {#pages-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.

Recurring maintenance scheduling {#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 {#monitor-maintenance-impact}

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-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 {#new-and-improved-capabilities}

User subscriptions and admin workflows {#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 {#customizable-email-templates}

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

Announcement banner {#announcement-banner}

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

Embed and event visibility improvements {#embed-and-events-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-calculation-flexibility}

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

Rendering and dashboard UX upgrades {#rendering-and-dashboard-upgrades}

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

Upgrade checklist from v3 {#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. Revalidate subscription data/flows against the new v4 system.
4. Audit integrations/scripts for removed v3 API routes.
5. Regenerate or re-import API clients from static/api-references/v4.json.
6. Validate custom domain + ORIGIN and auth form behavior in production.