Agreed. ĐANG XÁC MINH is closer to “verifying/confirming” and can imply that the cause is already being checked. In this incident-management context, INVESTIGATING refers to the earlier phase where the team is still looking into the issue, so ĐANG ĐIỀU TRA is more accurate and clearer for Vietnamese users.
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
- Import GetAllSiteData directly from siteDataController instead of the
controller barrel, which re-exports incidentController and creates a
circular import (risk of partially-initialized modules at runtime).
- Pass a stable per-comment deduplication id to subscriberQueue.push so a
retried/double push notifies once; without it the queue falls back to a
Date.now()-suffixed id that never deduplicates.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Manually created/updated incidents never reached the subscriber
notification workflow (#774): only alertingQueue pushed to
subscriberQueue, so dashboard and API incidents stayed silent.
Make AddIncidentComment the single notification choke point: posting a
comment on an INCIDENT-type incident notifies "incidents" subscribers,
regardless of source (alert, dashboard, or API). Remove the two bespoke
pushes in alertingQueue — alert-driven incidents now notify through the
same path via their auto-created comments, instead of twice.
The dedup id is now the comment id (previously the incident id with a
Date.now() suffix, which never deduplicated anything). Alert-created
incident emails now carry the incident state (INVESTIGATING) instead of
the alert status (TRIGGERED) in the subject; body content is unchanged.
Also drop the dead commented-out queueController blocks left from the
old notification system.
Fixes#774
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The field was already stored in the DB, mapped through the controller,
and present on MonitorRecordTyped — but missing from CreateMonitorRequest
and UpdateMonitorRequest, so the API silently dropped it.
- layoutController/site-configurations: use strict boolean check instead of
Boolean() coercion for showInlineEvents so persisted "false" strings don't
flip the toggle
- (kener)/+page.svelte: collapse confusing triple negation !!! to single !
- NotificationsList: add aria-label/title to the icon-only events button
(+ "Open events page" en locale key)
- move NotificationEvent into shared $lib/types/notifications so client code
no longer imports from the server dashboardController; controller re-exports
it for backwards compatibility
- [page_path] and monitor pages: pass hideNotificationsPopover={showInlineEvents}
to ThemePlus so inline and popover event surfaces stay mutually exclusive
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
GET / was throwing KnexTimeoutError ("Timeout acquiring a connection")
in production. Root cause was the connection pool, not the database:
the single process (SvelteKit + cron scheduler + BullMQ workers) shared
one pool capped at 10, while one GET / fans out ~6 queries. A couple of
concurrent page loads, or a per-minute monitor burst overlapping a load,
exceeded 10 and queued acquires blew past the 15s timeout. Postgres
itself had 97 free slots the whole time and no leak.
Split into two pools so background work can't starve page loads:
- web pool (DATABASE_POOL_MAX, default 10) serves HTTP requests
- worker pool (DATABASE_WORKER_POOL_MAX, default 5) serves background jobs
Routing is by execution context via AsyncLocalStorage: q.createWorker
(the single chokepoint all workers/schedulers flow through) runs each
processor inside a worker-pool context, and BaseRepository.knex resolves
the pool from that context, defaulting to the web pool. This keeps shared
controllers correct whether they run in a request or a job. SQLite has no
real pool and reuses a single connection, so the split is a no-op there.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ioredis v5 dropped the namespace merge on the default export, so
`Redis.RedisOptions` resolves to TS2702 (type used as a namespace).
Import the `RedisOptions` type by name instead.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The per-row status+note backfill is one logical confirmation flip; wrap the
read+updates in a knex transaction so a mid-loop failure can't leave the window
half-confirmed/half-held (coderabbit out-of-diff finding).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- PATCH: confirmation_threshold:null resets to 1 (off); undefined keeps existing (Copilot)
- backfill note is per-row severity-aware: 'Down'/'Degraded confirmed after N…' (Copilot)
- enforce 1–60 at the data layer via clampConfirmationThreshold on insert/update,
covering all app write paths incl. the manage API (coderabbit)
- anchor via dedicated getLastObservedStatus query so a long incident/maintenance
window can no longer push the anchor out of the lookback and bypass damping (coderabbit)
- overlays fetched AFTER execute() and keyed by job ts, making the freeze gate
timestamp-safe and catching mid-check overlays (coderabbit + greptile)
- use Array.includes over indexOf!==-1 (greptile); refresh pendingHold doc (coderabbit)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
New v4/monitors/grace-period.md covering behavior, config, API, interactions
(alerts/maintenance/NO_DATA/groups/heartbeat), and verification; linked from the
Monitors sidebar and the Monitors Overview related-docs.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Broaden the ignore from the single 0009 ADR to the entire docs/adr/ directory and
untrack the existing ADRs (0001-0008); files are kept on disk and remain in history.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
gitignore + untrack CONTEXT.md, docs/adr/0009-*, and docs/superpowers/ (files kept
on disk). Remove the 'ADR 0009' citations from code comments; issue references and the
pre-existing ADR 0005 citations are retained.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Held (pending) rows now keep the real error text tagged '| Status held during
grace period' instead of dropping it, so no diagnostic info is lost. On confirmation
the backfill appends '| Down confirmed after N consecutive checks' to the existing
text (pipe-separated) rather than overwriting it; recovery clears the error. Append
is per-row for cross-DB safety and idempotent on replay.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
A pending (held) row was written with latency 0, losing the measured latency and
denting the latency chart during every grace window (and discarding a recovering
check's real latency). Keep the observed latency; only drop the error text so a
held row never shows a status-contradicting failure message.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Replaces getRecentObservedSamples with getRecentSamplesForConfirmation, which adds
INCIDENT/MAINTENANCE overlay rows and the `type` column to the result set so the
Confirmation Threshold resolver can detect freeze boundaries. MANUAL and DEFAULT
rows remain excluded (transparent). Adds OVERLAY_TYPES constant alongside the
existing OBSERVED_CHECK_TYPES. Updates dbimpl.ts declaration and binding to match.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Review follow-up on #754: deleteMonitorAlertConfigsByMonitorTag removed
v2 alert rows only when the whole config died, so a shared config that
survived the detach kept monitor_alerts_v2 rows pointing at the deleted
monitor's tag. Verified red/green with an in-memory SQLite script:
the deleted tag's v2 rows now go with the detach while the surviving
monitors' rows are untouched.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Monitor deletion is now available via the v4 API, reusing the same
DeleteMonitorCompletelyUsingTag path as the manage UI. While wiring it
in, monitor deletion was found to orphan alert configs on SQLite:
the code relied on FK cascades that SQLite never enforces (the
foreign_keys pragma is off). Delete paths now remove child rows
explicitly — v2 alerts, trigger junctions, monitor junctions — in both
the by-id and by-tag config deletes; see ADR 0008 for why explicit
deletes were chosen over enabling the pragma.
Also corrects the CONTEXT.md Stale Member entry (deletion strips group
membership and rebalances weights; only pausing produces a stale
member), documents the DELETE endpoint in the OpenAPI spec, points the
pages doc at the ~home token, and removes an orphaned fictional
api-reference markdown page superseded by the spec tab.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Maintenance descriptions rendered as plain text in MaintenanceItem, so
HTML tags and line breaks showed literally on the home page while the
maintenance detail page rendered them correctly. Use the same
SveltePurify + mdToHTML prose pattern as the detail page and incident
comments.
Fixes#713
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Introduce functionality to manually complete or cancel ongoing maintenance events.
- Update event status to COMPLETED or CANCELLED, adjusting end_date_time accordingly.
- Ensure terminal statuses prevent further modifications and notify subscribers of changes.
- Revise API to support status transitions alongside window edits, enforcing mutual exclusivity.
- Document behavior and consequences of manual transitions in ADR.
A maintenance with is_global=YES (the default) has no per-monitor rows, so
the feed builder dropped it via the monitors.length===0 guard intended to
hide events whose monitors are all hidden. Global maintenances therefore
never appeared in /rss.xml, even though they show on the public events page.
Carry is_global through getMaintenanceEventsForEventsByDateRange and the
shared monitor-list grouping, then keep global events in the feed while still
dropping non-global ones whose monitors are all hidden. Global items render
"Affected: All monitors".
Two fixes verified E2E with playwright before pushing:
1. The feed window bounded maintenances to (now - 90d, now), excluding
any SCHEDULED maintenance with a future start_date_time. Split the
range so incidents keep their past-only window but maintenances span
(now - 90d, now + 90d), so subscribers learn about upcoming windows
alongside historical ones. Incidents are still past-bounded.
2. Mirror the subMenuOptions.showRssFeed toggle on the Subscriptions
admin page. RSS is a notification channel alongside email subs, so
admins thinking about subscriber-facing surface area shouldn't have
to bounce to Site Configurations to manage it. Same backing
site_data key — toggling either place updates the other on reload.
The feed routes (/rss.xml etc) stay reachable when the toggle is
off; the toggle only controls the in-page icon button.
Review feedback on #747:
- Wrap alertingQueue.push in try/catch in both data PATCH endpoints — the
sample is already committed, so a Redis/BullMQ outage must not turn a
successful write into a 500 (which would invite client retries and
duplicate MANUAL rows).
- Compute lastWrittenTs with GetMinuteStartTimestampUTC(body.end_ts) —
UpdateMonitoringData floors both bounds to minute starts and writes
through the floored end inclusive, so the previous raw-offset formula
could name a timestamp no stored row has when start_ts was unaligned.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Addresses coderabbit review on #746: the bounds checks allowed decimals.
Number.isInteger is now part of the validity deriveds in the monitor-level
status history card, and the pages editor gains the same guard (it previously
saved display settings with no validation at all) plus step=1 and error
styling on the inputs.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Addresses coderabbit's outside-diff comment on #746: isDesktopValid and
isMobileValid are derived once and reused by isValid and both input error
states, instead of repeating the bounds check four times.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Address coderabbit review on #746:
- toApiPageSettings runs type-filtering sanitizers over stored incidents and
include_maintenances so wrong-typed leaves (enabled: "yes",
max_count: "five") never override defaults in responses
- validatePageSettings checks every known leaf: booleans for enabled/show,
non-negative integers for max_count/days fields
- DeepPartial recurses only into plain object maps; arrays pass through
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Address review feedback on #746:
- applyPageSettingsPatch now deep-merges the mapped patch into the stored
JSON: nested unknown keys survive, untouched siblings survive, and extra
client keys are persisted as the schema's additionalProperties allows
- toApiPageSettings normalizes invalid stored values (unknown layout style,
out-of-range or non-integer history days) so responses always satisfy the
OpenAPI enum and bounds
- new PageSettingsPatch (DeepPartial) type lets TS clients send partial
nested updates like { monitor_status_history_days: { mobile: 14 } }
- incidents / include_maintenances and their known sub-objects are now
validated as objects (incidents: 123 returns 400)
- CONTEXT.md wording: the UI and API expose the same settings, surfaces may
name fields differently
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
DeletePage in pagesController already enforces this invariant for the manage
UI (the UI's delete confirm for home was always rejected server-side), and
the public site root assumes the home page exists. Before the ~home token
the v4 DELETE could never reach the home page; now that it can, it returns
400 like the rest of the app.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
What a consumer reads is now exactly what it can address: the list, single,
and write responses all show ~home for the home page instead of an empty
string, so list -> pick -> PATCH round-trips cleanly. Read-modify-write
bodies that send ~home back are treated as no path change. The token moves
to global-constants as HOME_PAGE_TOKEN.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The home page is stored with an empty page_path, which can not appear as a
URL segment, so /api/v4/pages/{page_path} could not address it at all. The
middleware now maps the special segment ~home to the empty-path lookup. The
token can never collide with a real page because the path sanitizer strips
tildes, and tilde is RFC 3986 unreserved so clients never need to encode it
(percent-encoded %7Ehome works too).
Semantics follow the manage UI: PATCH via ~home accepts every field except
page_path, which is fixed for the home page, and DELETE is allowed.
Requests to /api/ paths with no matching route (e.g. GET /api/pages/) now
return a json NOT_FOUND error instead of SvelteKit's html error page.
Documented in the OpenAPI spec (PagePath parameter + PATCH note), ADR 0004,
and the CONTEXT.md glossary.
Fixes#737
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Address review feedback on #744:
- clamp DATABASE_POOL_MAX to >= 1 and DATABASE_POOL_MIN to <= max so bad
env values can not produce a pool that fails every acquire
- healthcheck redis probe checks client status before PING so commands are
not queued indefinitely while redis is down (maxRetriesPerRequest is null)
- probe() clears its timeout timer once the check settles
- error.html shows only the status code, not the error message
- docs: correct SQLite default to kener.sqlite.db to match knexfile
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Address review feedback on #742:
- GetSiteURL now only returns absolute http(s) origins, falling back to the
ORIGIN env var when the stored siteURL is unset or scheme-less, so the v4
url fields honor the OpenAPI format: uri contract
- event status casts now use the response interface types
(MaintenanceEventResponse["status"], MaintenanceEventDetailResponse["event_status"])
so READY is included and the casts can not drift from the API contract
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The public /maintenances/<id> route is keyed by maintenance EVENT id by
default, while /api/v4/maintenances returns maintenance ids. Consumers
that concatenated API ids onto the public path landed on the wrong page
(#723) — an apparent off-by-one title mismatch with no actual data
corruption.
Instead of flipping the route default (which would break every internal
link, subscriber email, and bookmarked URL), v4 API responses now carry
an absolute `url` field built from the configured Site URL:
- Maintenance responses link via /maintenances/<id>?type=maintenance
- Maintenance event responses link via /maintenances/<event_id>
- Incident responses link via /incidents/<id> (parity)
Also updates the OpenAPI spec, records the decision in
docs/adr/0002, and pins Maintenance vs Maintenance Event in CONTEXT.md.
Fixes#723
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The sticky theme-plus bar has no background, and the gap between it and the
fixed nav stays transparent, so page content shows through both sections as
it scrolls. Paint one blurred layer behind both (above content, below nav
z-10 and bar z-20).
ThemePlus now renders a small Rss icon-button next to Subscribe / share
controls, scoped to the current view (monitor / page / default) and
opening the feed in a new tab. Gated on subMenuOptions.showRssFeed
(defaults true) so admins can hide it via Manage → Site Configurations →
Monitor Sub Menu Options without losing the underlying feed routes.
Adds RSS feed key to all 22 locale files (untranslated; RSS is a tech term).
New route GET /monitors/{monitor_tag}/rss.xml serves a feed scoped to a
single monitor (404s for hidden, inactive, or unknown monitors). Existing
page-scoped routes are unchanged in URL; renderRssFeedResponse now takes
a discriminated scope arg so all three routes share one handler.
The (kener) layout emits a <link rel="alternate" type="application/rss+xml">
in <head>, scoped to the current view: monitor page -> monitor feed,
named status page -> page feed, otherwise default. Lets feed readers and
browsers discover the feed automatically. Title attribute is hardcoded
(machine-facing) so no locale files are touched.
Exposes /rss.xml (default page) and /{page_path}/rss.xml (named pages).
Items inherit visibility from the existing events-by-month data path:
hidden monitors are stripped, KENER_BASE_PATH is honored in absolute
links, and forceExclusivity is respected on the default route.
Feed window: last 90 days, 50 most-recent items, sorted desc.
Response: application/rss+xml; charset=utf-8, Cache-Control max-age=300.
404 on unknown page_path or when siteURL is not configured.
Adds a Core Concepts doc page covering URLs, item shape, and verification.
No user-facing UI text; i18n locales untouched.
- Modify alertToVariables function to accept an optional monitorTag parameter for better flexibility in alert naming.
- Update sendAlertNotifications function to pass monitorTag to alertToVariables.
- Enhance addWorker function to handle multiple monitors by querying and creating alerts with the appropriate monitorTag.
- Introduce a new junction table for many-to-many relationships between monitor alerts and monitors.
- Update database migration to accommodate the new schema and backfill existing data.
- Revise frontend components to support multiple monitor selections in alert configurations.
- Enhance documentation to include analytics provider setup instructions.
implements #675
feat(dashboard): Refactor notification payload to include event start and end times
refactor(controllers): Modify group call scoring model to use normalized scores for status
docs(changelog): Document changes in group monitor scoring model in v4.0.14 release notes
feat(badges): Implement locale selection for status badges in management interface
refactor(i18n): Create server-side i18n helper for translating strings outside of Svelte components
- Revise site configuration documentation to clarify page visibility behavior.
- Introduce global page visibility settings with detailed descriptions and functionality.
- Modify API server to dynamically select the correct specification path based on environment.
- Streamline event fetching logic in event pages to improve performance and maintainability.
- Remove unused vault secret management code from the manage API.
- Enhance customizations page to support global page visibility settings.
- Create new guides for adding custom fonts and custom JavaScript/CSS.
- Implement server-side logic for handling events by month with improved date validation.
feat(links): Correct URL formatting in invitation and verification email links
refactor(notification): Simplify notification utility imports
chore(docs): Update Discord link and API reference URLs in documentation
style(buttons): Change button variant for better UI consistency
chore(scripts): Implement script to sort translation keys in locale files
- Implement multi-stage Dockerfile for building and running the Kener application with support for Alpine and Debian variants.
- Establish development and production Docker Compose files for local testing and deployment.
- Configure Redis service for caching and job scheduling.
- Set up environment variables for application configuration, including secret keys and database connections.
- Define health checks for Redis service to ensure reliability.
Add comprehensive skill file for creating and editing high-quality Kener documentation with guidelines for:
- Documentation structure and organization
- Custom heading anchors for deep linking
- Markdown features and formatting
- Quality guidelines and best practices
- Avoiding content duplication with references
- Complete workflow and checklist
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Co-authored-by: rajnandan1 <16224367+rajnandan1@users.noreply.github.com>
refactor: Modify alertToVariables function to streamline alert data handling
refactor: Change alert_id and alert_incident_id types in types.ts for consistency
refactor: Simplify alert notification templates to include incident URL and update variable types
docs: Update alerting templates documentation to reflect new variables and structure
refactor: Enhance webhook alert template to accommodate new incident URL handling
refactor: Adjust server API to utilize the latest monitor tag for testing alerts
- Create UserRecordDashboard interface to include password status.
- Update password reset API to validate password strength and set user as verified.
- Refactor invitation handling in the manage route to streamline user management.
- Introduce invitation acceptance flow with password creation and validation.
- Create email template for user invitations.
- Implement invitation verification logic to ensure token validity and user existence.
- Enhance user management UI to support invitation resending and account activation.
The API reference page was blank because spec.content expected a parsed
JSON object but received a JSON string. Added JSON.parse() to properly
parse the OpenAPI spec before passing it to @scalar/express-api-reference.
Fixes#532
- Set Russian as default locale in seedSiteData and i18n server configuration
- Replace MMMM with LLLL format for proper Russian month declension (nominative case)
- Update all date format strings across incident pages and controllers
- Add date range validation (2023 to current+12 months) with 404 error handling
- Implement conditional navigation buttons that hide at date boundaries
- Fix Russian month names display (октябрь instead of октября in titles)
- Add MIN_YEAR constant to prevent navigation before system launch
- Improve TypeScript compatibility and fix linter errors
This resolves Russian grammatical issues and prevents access to invalid date ranges
while maintaining proper localization and user experience.
Refactors the subscription status toggle to use a dedicated handler, ensuring correct behavior when toggling status for both new and existing triggers. Enhances user experience by automatically saving and reloading data when needed.
Adds support for toggling the subscription trigger's active/inactive status from the UI and updates backend/controller logic to allow dynamic status changes. Restricts editing of subscription event configuration and user subscriptions to when the trigger is active, improving admin control and preventing unintended changes when subscriptions are inactive.
Returns structured error messages from notification providers, updates API logic to surface errors to users, and enhances UI to display error or success states during trigger tests. Also adjusts monitor API request payload and corrects data range calculation.
Relates to improved reliability and user experience.
Introduces per-device configuration for maximum data range and selectable days on the homepage, allowing separate settings for desktop and mobile. Updates UI, server logic, and data model to support these options, and uses user agent detection to apply the correct configuration. Improves flexibility for data display across devices.
Relates to #105
Introduces a 'tz' parameter for specifying timezone in embed scripts and iframe URLs, improving localization for embedded monitors.
Updates documentation and refactors parameter handling to prioritize explicit timezone over browser-detected values.
Relates to improved internationalization and user experience.
Enhances subscription menu by showing a default icon when no image is available.
Replaces hardcoded verification code in email template with a variable.
Prevents background scrolling when subscription menu is open.
Removes redundant new subscriber response in API.
Removes unused documentation button from subscriptions page.
Adjusts checkbox styling for better UI consistency.
Introduces a unified function for monitoring data insertion,
adds support for group monitor status updates, and ensures
consistency by routing all monitoring data writes through the
new logic. Removes duplicated validation and streamlines
group monitor handling for improved reliability.
Relates to #123
Introduces an option to enable a site status banner summarizing the operational state of monitored systems. Calculates and displays aggregated status with a progress bar. Localizes banner messages in all supported languages.
Helps users quickly assess overall system health from the homepage.
- Updated monitorSheet.svelte to use raw JSON data for AllGamesList, replacing the previous import method.
- Refactored game retrieval logic in monitorSheet.svelte to utilize GetGameFromId function with the new AllGamesList structure.
- Modified monitorsAdd.svelte to parse AllGamesList from raw JSON, ensuring consistent data usage across components.
- Enhanced event pages (+page.svelte) with appropriate meta tags for better SEO, including titles and descriptions.
- Added a new all-games-list.json file containing comprehensive game data for improved functionality and maintainability.
- Updated subscriptions page to clarify SMTP setup instructions for users.
Integrates translation function into subscription and maintenance components,
localizing all user-facing strings. Expands translation resources for multiple languages
to cover newly localized phrases, improving accessibility and user experience for non-English users.
Unifies URLs for incident events by switching from singular to plural path segments and removes obsolete routes to streamline navigation. Introduces paginated incident fetching with filtering and sorting to improve performance and scalability. Updates UI components to reflect new paths and behaviors.
Relates to improved incident management and navigation.
Introduces a copy-to-clipboard button for incident links with animated feedback. Adds ability to hide accordion chevrons and refactors chevron and copy button styles. Updates incident URL generation and allows querying monitors by tag.
Relates to improved UX for incident management.
Introduces a queue-based system to send email notifications for incident events, including creation, updates, monitor changes, and comments. Fetches eligible subscribers dynamically and uses configurable templates for email delivery. Also updates the UI to improve the Preview button styling for better user experience.
- Implemented GenerateTokenWithExpiry function for JWT token generation with a specified expiry time.
- Added GetSubscriberByID function to retrieve subscriber details by ID.
- Updated CreateNewSubscription to accept subscriber ID directly.
- Introduced GetSubscribersPaginated for paginated retrieval of subscribers.
- Enhanced subscription trigger management with CreateSubscriptionTrigger and GetSubscriptionTriggerByEmail functions.
- Updated email_code.html to change expiration notice from 1 day to 5 minutes.
- Modified layout.server.js to include canSendEmail check for conditional rendering.
- Updated subscription page to display subscribers with pagination and subscription status management.
- Refactored subscription-related API endpoints for improved clarity and functionality.
- Added server-side logic for managing subscription triggers and email settings.
- Added functionality to create, update, and delete subscribers and their subscriptions in the controller and database implementation.
- Introduced new API endpoints for subscribing and unsubscribing users, including email verification and management of subscription preferences.
- Created a new Svelte component for managing subscriptions, allowing users to subscribe to updates and manage their preferences.
- Added email template for sending verification codes to subscribers.
- Implemented utility functions for generating random numbers and validating email addresses.
Sometimes, it's useful to modify data in the monitoring_data table, for example, in case of a false positive.
I'm adding a new button in the monitor list that opens a popup
allowing users to change the status of monitor data for a given time
range.
feat: modify analytics event naming convention for consistency
fix: adjust delete monitor confirmation form layout for better UX
style: refine positioning of monitor action buttons for improved alignment
refactor: streamline password validation imports in setup and forgot password routes
fix: remove unnecessary line breaks in layout server file
Implements badges for monitors, including status, uptime, and liveness, along with a dedicated management page.
Adds embed options for various platforms with customizable styles.
Implements role-based access control with admin, editor, and member roles.
Introduces a user management system with profiles, activation/deactivation, and password reset.
Adds an email authentication system with verification and password reset via email.
Includes an invitation system with token-based invitations and admin controls.
Improves performance, security, UI, and developer experience.
Updates package version to 3.2.5 and adds vite-plugin-package-version.
Removes libcap related code from Dockerfile.
Improves the incident display by adding time status information
such as "Starts in", "Started", and "Will last for".
Also fixes database directory write permissions on startup.
Also fixes#337
- Makes the monitor tags wrap on smaller screens.
- Validates webhook body.
- Adds user agent to webhook.
- Fixes Discord logo URL construction.
Issue #336
Implements the SQL monitor feature, allowing users to monitor database connections and queries.
Adds UI elements for configuring SQL monitor parameters, including connection string, query, and timeout.
Validates user inputs for SQL monitor configuration.
Improves date formatting by adding timezone support using `date-fns-tz`.
Allows users to switch between different timezones via a new UI toggle in the settings.
Updates dependencies and integrates timezone functionality into date formatting functions.
Refactors the monitor component for better data display and user interaction, including improved uptime calculations and a dropdown for selecting time ranges.
Enhances incident creation and handling by adding incident sources and refining incident filtering.
Addresses UI responsiveness on smaller screens.
Improves incident management by filtering out existing auto incidents when creating manual incidents.
Enhances cron job scheduling by removing and adding jobs dynamically based on active monitors and prevents duplicated incidents.
Also, ensures jobs get triggered in the correct order.
Simplified Docker tagging - in turn fixes broken `alpine` tag to correctly point to latest stable Alpine release. Changes include:
- No more type=ref,event=branch – because this workflow is only for releases & manual triggers on `main` branch.
- Ensures `alpine` tag is always created for Alpine variant builds.
- Ensures `latest` tag is always created for Debian builds.
- Ensures all semver-based tags work correctly for both variants.
Improves incident display and management by introducing configurable incident group views and enhancing comment rendering to support HTML content.
Solves the bug raised in #295 where server crashes when an incident is created from an alert
Refines SMTP email settings by adding TLS configuration and allowing username/password to be optional. #300 and #298
Also, fixes a bug where only home page was being filtered. Now all pages are filtered. #297
Adds job to check if any Dependabot PRs are open and if so, fail the Docker build (since we need to ensure OS packages exist and are in their correct versions when using pinned versions for security purposes).
Noticed multiple individuals commenting about insecure/privacy-unfriendly Lato webfont library being served via Google Fonts. I had formerly suggested replacing this with BunnyFonts and was happy to see that added as a placeholder, however, I also understand someone’s comment about this being loaded from an external resource.
This brings that webfont local. Size of webfont files should minimally grow Docker image sizes and I think we should prioritize UI and privacy by including it locally. The font’s licensing is OFL, so we are allowed to package it for distribution with this project.
I’m including both the full font family (for archival purposes) and Latin subset of this font. The Latin variant is used in the Docker image build (since this will apply to the majority of users and keep the Docker image smaller). If users need to extend this with their own subsets, they can always load those as a custom font. :)
Adds a NO_DATA status to handle cases where monitor data is unavailable.
Refactors data interpolation and aggregation logic for better accuracy and clarity.
Updates documentation links.
fixes#288
Updates the Kener version from 3.1.2 to 3.1.3.
Refactors the group query to use `havingRaw` for better compatibility across different database systems.
Adds database information to the bug report template.
Updates documentation to reflect the new directory structure.
The documentation now correctly references images in the `/documentation` directory.
Removes the `src/static/documentation` directory in the Dockerfile.
Not sure if we are wanting Dependabot to track Node.js packages, so for the time being, commenting this block out, but leaving for now w/ “TODO” to come back to at a later point.
Changed from trying to use artifacts and the GHA workflow failing to now using a simple `BUILD_VERSION` repository variable and automatically updating that when the `build-and-push-to-registries` workflow succeeds.
Other changes include:
* Added `workflow_run` trigger to `generate-readme.yml` so when that workflow recognizes the “Publish Docker Image to Registries” workflow runs and succeeds, it will automatically run the `generate-readme.yml` workflow (since a new Docker release will require Docker image variants table in README.md to have versioning updated)
* Generate major and major-minor versions from the `BUILD_VERSION` repository variable (more efficient than storing three separate variables from the `build-and-push-to-registries` workflow job)
Changes include:
* Moving README generation to separate workflow (so that it can be trigger to run when any changes to `README.template.md` are pushed to `main` branch or a PR is opened with changes to template file
* GitHub Actions do not have privileges via `GITHUB_TOKEN` to commit to protected branches, thus, we need to take another approach and utilize a personal access token (which you’ll need to generate @rajnandan1) and add to the repository secrets (to avoid exposing that credential).
* Changes `publish-images` workflow to run now only when a new GitHub Release is created. (This will help prevent excessive workflow runs on merges into `main`)…in other words, @rajnandan1, you can merge freely into `main` now without excessive GitHub Actions usage.
The following changes have been made:
* Ensured `package-lock.json` is up-to-date with latest dependencies from `package.json` - moved check to new workflow job and set as dependency for ‘build-and-push-to-registries’ job
* Updated branch-tagging for non-main branches (used when building Docker images)
* Restored pinned OS package versions in Dockerfile (for best-security)
* Restored “TODO” comments to Dockerfile (for tracking purposes and because I will revisit those items later this week)
* Added `—no-fund` tag to suppress npm package funding messages (helpful for CI/CD)
* Changed from `wget` to `curl` to resolve Debian package versioning issue between differing architectures (was one of the reasons causing the build to fail)
* As a part of the last comment, needed to then conditionalize container healthcheck logic
* Checked in newest `package-lock.json` file
* Fixed broken Docker badges in `README.template.md`
🔄 Automate README Generation via Mustache Templating
- Use Mustache to dynamically generate `README.md` from `README.template.md`.
- Populate README with environment variables (e.g., `KENER_BUILD_FULL_VERSION`).
- Prevent direct edits to `README.md` by enforcing updates via the template.
- Enhance GitHub Actions workflow to auto-generate and commit the README.
- Add GitHub Action workflow (`protect-readme.yml`) to prevent others from direct updates to `README.md` via PR.
I caught an issue where the README will only auto-update listed Docker versions the first time. Commenting out for now (in case this PR gets merged before I have time to fix this). Will revisit this and fix this week.
Integrating Dependabot into the workflow ensures automatic dependency updates, improving security, reducing technical debt, and keeping packages up to date with minimal manual effort. This helps prevent vulnerabilities and maintain code stability over time.
Dependabot will automatically monitor the project’s dependencies and open pull requests (PRs) to update them when new versions are released. Here’s how it works:
1. Scans for Outdated Dependencies – It checks project dependency files (e.g., package.json, Dockerfile, .env.build, etc.) for outdated versions.
2. Fetches Latest Versions – When a newer version of a dependency is available, Dependabot retrieves it and updates the dependency files accordingly.
3. Opens a Pull Request – It then creates a PR with the updated dependency, detailing the changes and linking to release notes, changelogs, or security advisories.
4. Runs CI/CD Tests – If we end up setting up continuous integration (CI) tests, the PR will trigger the tests to check for breaking changes.
5. Security Updates – Dependabot also detects vulnerable dependencies and creates PRs to update them to a secure version.
6. Auto-Merging (Optional) – We might consider this at a later point, but if configured, it can automatically merge PRs when updates pass all tests and meet the requirements.
Noticed when doing some cleanup, that you had two awesome tags, but they both point to different URLs/repos. I added back in the one I had inadvertently removed.
* Expanded upon existing Docker README section.
* Created table which will contains version placeholder variables that will be replaced by new GitHub workflow job: “update_readme”. Job automatically runs after new images have been built & pushed to container registries.
Default documentation link in main nav won’t work because /docs are not included in built Docker images (to keep image smaller). Instead, changing seed data to point to the docs homepage. :)
Switching from Google Fonts to Bunny Fonts CDN. Bunny Fonts is an open-source, privacy-first web font platform. It is fully GDPR compliant (Google is not) and can act as a drop-in replacement for Google Fonts.
Streamlined the GitHub `publishImage.yml` workflow with the following functionality:
* Handle both Alpine and Debian variants through matrix strategy
* Push to both Docker Hub and GitHub Container Registry
* Add comprehensive tagging strategy, handling both branches (aka release version, e.g. 1.0.0), semantic versions (major.minor and major), and latest versions (`latest` and `alpine`)
* Add security aspects (cosign signing, proper permissions)
* Add better caching and multi-platform build settings
With this revised workflow, the following Docker image variants will be built for every successful release. As an example, if the release version is “3.0.9”, then the following Docker image variants will be built:
Debian variants (default):
- `kener:3.0.9` (Semver of current release)
- `kener:latest` (Latest Debian release, ’latest’ label points to 3.0.9)
- `kener:3.0` (major.minor version, major.minor ‘3.0’ label points to 3.0.9)
- `kener:3` (major version, major ‘3’ label points to 3.0.9)
Alpine variants (smallest filesize):
- `kener:3.0.9-alpine` (Semver of current release)
- `kener:alpine` (Latest Alpine release, ‘alpine’ label points to 3.0.9)
- `kener:3.0-alpine` (major.minor version, major.minor ‘3.0-alpine’ label points to 3.0.9)
- `kener:3-alpine` (major version, major ‘3-alpine’ label points to 3.0.9)
* Switch to multi-stage build pattern for smaller image size
* Add support for both Alpine and Debian variants via build args
* Change default image base to `node:23-slim` instead of using `node:23` (no need for full Debian base present in `node:23` since now prioritization is given to production-ready builds)
* Improve caching with --mount for npm dependencies
* Separate build and runtime dependencies
* Remove unnecessary Node.js packages in final stage
* Fix permissions on uploads/database directories
* Add proper scoping for build arguments
* Set NODE_ENV=production for better performance
This change reduces the final image size and improves build caching while adding flexibility to choose between Alpine and Debian base images.
Original: ~1.2GB
New Alpine: ~350MB
New Debian: ~450MB
When building for production, various warnings are output which slows down production build.
The following changes were made:
- Suppress unused export properties (unused-export-let).
- Suppress conflicting Svelte resolve warnings (conflicting-svelte-resolve).
- Suppress empty chunk warnings (empty-chunk).
- Suppress unused module imports (module-unused-import).
- Keep other important warnings visible, so we’re still aware of potential issues.
Now, production build should be cleaner and faster! 🚀
- Added Russian language support by creating ru.json with translations for various terms and phrases.
- Updated locales.json to include Russian in the list of available languages.
Use the right shadcn-svelte components when building UI in SvelteKit projects. This skill detects your project setup, shows what's available, and gives you access to full component documentation.
## Prerequisites
The project must be a SvelteKit app with shadcn-svelte initialized:
```bash
# Initialize shadcn-svelte in an existing SvelteKit project
npx shadcn-svelte@latest init
```
## How to use
### Step 1: Detect project setup
Run the detection script to verify this is a SvelteKit project with shadcn-svelte and see which components are already installed:
```bash
bash <skill-path>/scripts/detect.sh .
```
This will:
- Confirm it's a SvelteKit project (checks for `svelte.config.js/ts` and `@sveltejs/kit` in package.json)
- Confirm shadcn-svelte is installed (checks for `components.json`, `bits-ui`, or `shadcn-svelte` in package.json)
- List all currently installed components in the project's UI directory
- Provide the documentation URL
If the script exits with code 1, the project either isn't SvelteKit or doesn't have shadcn-svelte — do not proceed with shadcn-svelte components in that case.
### Step 2: Read the component documentation
The full component documentation for LLMs is available at:
```
https://www.shadcn-svelte.com/llms.txt
```
Fetch this URL to get a structured index of all available components organized by category, with links to individual component documentation pages (in `.md` format).
When you need to use a specific component, read its individual documentation page from the links provided in `llms.txt`. Each component doc includes:
- Import statements and usage examples
- Available props, events, and slots
- Variants and configuration options
- Accessibility information
### Step 3: Use the right component for the job
When building UI, follow this decision process:
1.**Run detection** to confirm shadcn-svelte is available and see installed components
2.**Fetch llms.txt** to see all available components
3.**Read the specific component docs** for the components you plan to use
4.**Check if the component is installed** — if not, add it:
```bash
npx shadcn-svelte@latest add <component-name>
```
5. **Import and use the component** following the documentation patterns
### Component categories
shadcn-svelte components are organized into these categories:
| **Form & Input** | Button, Calendar, Checkbox, Combobox, Date Picker, Input, Input OTP, Label, Radio Group, Range Calendar, Select, Slider, Switch, Textarea, Toggle, Toggle Group |
Components are typically imported from the project's `$lib/components/ui` directory:
```svelte
<script lang="ts">
import { Button } from "$lib/components/ui/button";
import * as Card from "$lib/components/ui/card";
import * as Dialog from "$lib/components/ui/dialog";
</script>
```
Some components use namespace imports (with `* as`) when they have multiple sub-components (Card, Dialog, Sheet, Table, etc.), while simpler components use named imports (Button, Input, Badge, etc.).
## Important guidelines
- **Always run detection first** before suggesting shadcn-svelte components
- **Always read component docs** before using a component — don't guess at props or patterns
- **Check installed components** and add missing ones before importing
- **Use the project's configured path** — the components directory may vary based on `components.json` configuration
if grep -q '"@sveltejs/kit"'"$PROJECT_DIR/package.json" 2>/dev/null;then
SVELTEKIT=true
fi
fi
if[["$SVELTEKIT" !="true"]];then
echo"NOT_SVELTEKIT"
echo"This is not a SvelteKit project. No svelte.config.js/ts found and @sveltejs/kit is not in package.json."
exit1
fi
# --- Step 2: Check for shadcn-svelte ---
SHADCN=false
# Check for components.json (shadcn-svelte config file)
if[[ -f "$PROJECT_DIR/components.json"]];then
# Verify it's actually a shadcn config (has $schema or style field)
if grep -qE '"(\$schema|style)"'"$PROJECT_DIR/components.json" 2>/dev/null;then
SHADCN=true
fi
fi
# Check for bits-ui in package.json (core dependency of shadcn-svelte)
if[[ -f "$PROJECT_DIR/package.json"]];then
if grep -q '"bits-ui"'"$PROJECT_DIR/package.json" 2>/dev/null;then
SHADCN=true
fi
fi
# Check for shadcn-svelte in package.json
if[[ -f "$PROJECT_DIR/package.json"]];then
if grep -q '"shadcn-svelte"'"$PROJECT_DIR/package.json" 2>/dev/null;then
SHADCN=true
fi
fi
if[["$SHADCN" !="true"]];then
echo"NO_SHADCN_SVELTE"
echo"SvelteKit project detected, but shadcn-svelte is not installed."
echo"Install it with: npx shadcn-svelte@latest init"
exit1
fi
# --- Step 3: Gather installed components ---
echo"DETECTED"
echo"SvelteKit project with shadcn-svelte detected."
echo""
# Check which components are already installed by scanning the components directory
COMPONENTS_DIR=""
# Try to read the components alias from components.json
if[[ -f "$PROJECT_DIR/components.json"]];then
# Extract the aliases.components path
ALIAS_PATH=$(grep -o '"components"[[:space:]]*:[[:space:]]*"[^"]*"'"$PROJECT_DIR/components.json"| head -1 | sed 's/.*"components"[[:space:]]*:[[:space:]]*"//'| sed 's/"//')
if[[ -n "$ALIAS_PATH"]];then
# Resolve $lib to src/lib
RESOLVED_PATH="${ALIAS_PATH//\$lib/src/lib}"
if[[ -d "$PROJECT_DIR/$RESOLVED_PATH/ui"]];then
COMPONENTS_DIR="$PROJECT_DIR/$RESOLVED_PATH/ui"
fi
fi
fi
# Fallback: check common locations
if[[ -z "$COMPONENTS_DIR"]];then
for dir in "src/lib/components/ui""src/lib/ui""src/components/ui";do
description: Specialized skill for creating and editing high-quality Kener documentation. MUST be used whenever creating or editing documentation files in the src/routes/(docs)/docs/content/ directory or updating docs.json navigation.
---
# Documentation Writer
Use this skill for all docs edits in `src/routes/(docs)/docs/content/` and when updating docs navigation in `src/routes/(docs)/docs.json`.
## Non-negotiable rules
1.**Be concise**: remove repetition and background that does not help the user complete a task.
2.**Be actionable**: prioritize “what to do” over theory.
3.**One source of truth**: if another page already has details, link to it instead of duplicating.
4.**Preserve structure**: keep valid frontmatter and heading anchor IDs.
5.**Keep examples copyable**: minimal, tested-looking, and directly relevant.
6.**Search before writing**: always check if the content already exists in some form before adding new sections or pages.
7.**Check Relevant Code**: Search the codebase inside `src/` for any relevant code, comments, or tests that can inform the documentation content and ensure accuracy.
## Docs config model (current)
`docs.json` is versioned. Sidebar lives inside tabs:
-`versions[].content.navigation.tabs[].sidebar`
- Sidebar groups contain `pages`
- Page paths use `content` (legacy `slug` may still appear in older content)
When adding a new doc page, add it to the appropriate tab sidebar path.
## Versioned link policy (mandatory)
- For v4 docs content, internal links MUST use explicit v4 paths: `/docs/v4/...`.
- Do not use unversioned shortcuts like `/docs/alerting/...` in v4 pages.
- Before finalizing, verify every internal link in edited files resolves to the intended version.
## Required page format
```markdown
---
title: Page Title
description: One-line summary of user outcome
---
```
- Use custom anchors for H2/H3 headings: `## Section {#section}`
- Use GitHub admonitions only when needed: `[!NOTE]`, `[!IMPORTANT]`, `[!WARNING]`, `[!CAUTION]`, `[!TIP]`
- Prefer short sections and short lists
## Preferred structure (default)
1. Short intro (1–2 sentences)
2. Quick setup / minimum config
3. Required variables/options table
4. Verification step
5. Top troubleshooting items
Only add extra sections if they materially improve task completion.
description: CLI tools for Svelte 5 documentation lookup and code analysis. MUST be used whenever creating or editing any Svelte component (.svelte) or Svelte module (.svelte.ts/.svelte.js). If possible, this skill should be executed within the svelte-file-editor agent for optimal results.
---
# Svelte 5 Code Writer
## CLI Tools
You have access to `@sveltejs/mcp` CLI for Svelte-specific assistance. Use these commands via `npx`:
### List Documentation Sections
```bash
npx @sveltejs/mcp list-sections
```
Lists all available Svelte 5 and SvelteKit documentation sections with titles and paths.
**Important:** When passing code with runes (`$state`, `$derived`, etc.) via the terminal, escape the `$` character as `\$` to prevent shell variable substitution.
## Workflow
1.**Uncertain about syntax?** Run `list-sections` then `get-documentation` for relevant topics
2.**Reviewing/debugging?** Run `svelte-autofixer` on the code to detect issues
3.**Always validate** - Run `svelte-autofixer` before finalizing any Svelte component
description: Tailwind CSS v4 utility-first styling patterns including responsive design, dark mode, and custom configuration. Use when styling with Tailwind, adding utility classes, configuring Tailwind, setting up dark mode, or customizing the theme.
user-invokable: false
metadata:
category: styling
---
# Tailwind CSS v4 Development Guidelines
Best practices for using Tailwind CSS v4 utility classes effectively.
**Note**: Tailwind CSS v4 (released January 2025) uses a CSS-first configuration approach. If you need v3 compatibility, tailwind.config.js is still supported.
## Core Principles
1.**Utility-First**: Use utility classes instead of custom CSS
2.**Mobile-First**: Design for mobile, then scale up with responsive modifiers
3.**Component Extraction**: Extract repeated patterns into components
4.**Consistent Spacing**: Use Tailwind's spacing scale
5.**Custom Configuration**: Extend the default theme for brand consistency
Thank you for considering contributing to our project! Here are some guidelines to help you get started.
---
## How to Contribute
1. Fork the repository and clone it locally.
2. Create a new branch for your feature or bug fix:
```bash
git checkout -b feature/your-feature-name
```
3. Make your changes and commit them:
```bash
git commit -m 'Describe your changes'
```
4. Push your changes to your fork:
```bash
git push origin feature/your-feature-name
```
5. Create a pull request to the `main` branch.
## Development
1. Install dependencies:
```bash
npm install
```
2. Create a `.env` file in the root of the project and add the following:
```bash
cp .env.example .env
```
2. Start the development server:
```bash
npm run dev
```
3. Open [http://localhost:3000](http://localhost:3000) in your browser.
## Documentation
The documentation is available in the `docs` folder. You can view it by going to [http://localhost:3000/docs/home](http://localhost:3000/docs/home) in your browser.
## Where to Start
1. Check out the [roadmap items](https://kener.ing/docs/roadmap/)
2. Add language support by following the [i18n guide](https://kener.ing/docs/i18n/)
Kener is an open-source status page application built with **SvelteKit 2.x** (**Svelte 5**) and **Node.js/Express**. It is a **TypeScript-first** codebase providing real-time monitoring, uptime tracking, incident management, and customizable dashboards.
## Architecture
### Dual Process Model
In development, `npm run dev` runs two parallel processes:
1.**SvelteKit dev server** (`vite dev`) - serves the frontend with HMR
In production, **`scripts/main.ts`** is the single entry point: Express server + SvelteKit handler + migrations + seeds + scheduler startup. Built output runs via `node build/main.js`.
- Route data loading: `+page.server.ts` / `+layout.server.ts`
- API endpoints: `+server.ts` files returning `json()`
## Types & Interfaces
Place types and interfaces in the appropriate folder based on where they are used:
- **`src/lib/types/`** - Shared types (safe to import from both server and client code). Use for domain models, DTOs, API response types, and anything needed on both sides.
- **`src/lib/server/types/`** - Server-only types (`db.ts`, `auth.ts`, `monitor.ts`, `api-server.ts`). Use for DB models, internal service types, auth/session types.
- **`src/lib/client/types/`** - Client-only types (`ui.ts`). Use for UI-specific types, component prop types.
Always use `import type { ... }` when importing types to avoid accidental runtime imports.
You are able to use the Svelte MCP server, where you have access to comprehensive Svelte 5 and SvelteKit documentation. Here's how to use the available tools effectively:
## Available MCP Tools:
### 1. list-sections
Use this FIRST to discover all available documentation sections. Returns a structured list with titles, use_cases, and paths.
When asked about Svelte or SvelteKit topics, ALWAYS use this tool at the start of the chat to find relevant sections.
### 2. get-documentation
Retrieves full documentation content for specific sections. Accepts single or multiple sections.
After calling the list-sections tool, you MUST analyze the returned documentation sections (especially the use_cases field) and then use the get-documentation tool to fetch ALL documentation sections that are relevant for the user's task.
### 3. svelte-autofixer
Analyzes Svelte code and returns issues and suggestions.
You MUST use this tool whenever writing Svelte code before sending it to the user. Keep calling it until no issues or suggestions are returned.
### 4. playground-link
Generates a Svelte Playground link with the provided code.
After completing the code, ask the user if they want a playground link. Only call this tool after user confirmation and NEVER if code was written to files in their project.
## Database compatibility rule
All database operations — migrations, queries, and repository functions — **MUST** work across all three supported databases: **SQLite**, **PostgreSQL**, and **MySQL**. Use Knex.js schema builder and query builder abstractions; avoid raw SQL unless wrapped in dialect-safe helpers or guarded with `try/catch`. When writing migrations:
- Use `knex.schema.hasColumn` / `knex.schema.hasTable` guards for idempotency.
- Use Knex column types (`.string()`, `.integer()`, `.text()`, etc.) — never raw `ALTER TABLE` unless necessary.
- For data-seeding inside migrations, use standard Knex query builder (`.insert()`, `.update()`, `.orderBy()`, `.first()`).
- Test that `defaultTo()` values and `notNullable()` constraints work on all three engines.
## Documentation writing skill
When the user asks to write or edit documentation, follow the skill file:
-`.claude/skills/documentation-writer/SKILL.md`
This is mandatory for docs-related tasks. Prioritize short, clear, action-oriented docs and avoid bloat.
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
## What is Kener?
Kener is an open-source status page application built with **SvelteKit 2.x (Svelte 5)** and **Node.js/Express**. It is a **TypeScript-first** codebase providing real-time monitoring, uptime tracking, incident management, and customizable dashboards.
## Development Commands
```bash
npm run dev # Start dev server (SvelteKit + cron scheduler in parallel)
npm run build # Production build (SvelteKit then esbuild server bundle)
npm run start # Run production build (node build/main.js)
npm run check # Svelte + TypeScript type checking
npm run prettify # Format all files with Prettier
npm run migrate # Run database migrations via Knex
npm run seed # Run database seeds (migrations run automatically first)
```
## Architecture
### Dual Process Model
In development, `npm run dev` runs two parallel processes:
1.**SvelteKit dev server** (`vite dev`) - serves the frontend
[](https://railway.com/deploy/spSvic?referralCode=1Pn7vs&utm_medium=integration&utm_source=template&utm_campaign=generic)
[](https://zeabur.com/templates/1YRTMI?referralCode=rajnandan1)
[](https://render.com/deploy?repo=https%3A%2F%2Fgithub.com%2Frajnandan1%2Fkener)
</p>
## What is Kener?
Kener: Open-source sveltekit status page system, crafted with lot of thought so that it looks modern.
**Kener** is a sleek and lightweight status page system built with **SvelteKit** and **NodeJS**. It’s not here to replace heavyweights like Datadog or Atlassian but rather to offer a simple, modern, and hassle-free way to set up a great-looking status page with minimal effort.
It does not aim to replace the Datadogs of the world. It simply tries to help someone come with a status page for the world.
Designed with **ease of use** and **customization in mind**, Kener provides all the essential features you’d expect from a status page—without unnecessary complexity.
### Why Kener?
✅ Minimal overhead – Set up quickly with a clean, modern UI<br>
✅ Customizable – Easily tailor it to match your brand<br>
✅ Open-source & free – Because great tools should be accessible to everyone
### What's in a Name?
“Kener” is inspired by the Assamese word _“Kene”_, meaning _“how’s it going?”_. The _‘.ing’_ was added because, well… that domain was available. 😄
-Manage incidents with clear timelines, updates, and acknowledgements
-Schedule maintenance windows and keep users informed throughout
-Send notifications via **Email, Webhook, Slack, and Discord**
-Explore historical monitoring data and uptime trends
### Customization and Branding
### 🎨 Status Page Experience and Branding
- Customizable status page using yaml or code
- Badge generation for status and uptime of Monitors
- Support for custom domains
- Embed Monitor as an iframe or widget
- Light + Dark Theme
- Internationalization support
-Build branded, customizable status pages (logo, colors, CSS, themes)
-Support **light/dark mode**, localization, and timezone-aware display
-Embed status widgets and badges into external sites and portals
-Provide SEO-friendly public pages for global audiences
### Incident Management
### 🛠️ Operations, Collaboration, and Automation
- Create Incidents using Github Issues - Rich Text
- Or use APIs to create Incidents
-Invite teams with role-based collaboration across workflows
-Manage multiple status pages from one Kener instance
- Use trigger-based workflows and template-driven messaging
- Manage API keys for secure integrations and automations
- Integrate analytics providers like GA, Plausible, Mixpanel, Umami, and Clarity
- Access the full REST API for incidents, monitors, and reporting
### User Experience and Design
## Technologies Used
- 100% Accessibility Score
- Easy installation and setup
- User-friendly interface
- Responsive design for various devices
- Auto SEO and Social Media ready
## Technologies used
- [SvelteKit](https://kit.svelte.dev/)
- [shadcn-svelte](https://www.shadcn-svelte.com/)
## Inspired from
- [Upptime](https://upptime.js.org/)
## Screenshots









-[SvelteKit](https://kit.svelte.dev/)
-[shadcn-svelte](https://www.shadcn-svelte.com/)
## Support Me
If you are using Kener and want to support me, you can do so by sponsoring me on GitHub or buying me a coffee.
If you’re enjoying Kener and want to support its development, consider sponsoring me on GitHub or treating me to a coffee. Your support helps keep the project growing! 🚀
[Sponsor Me Using Github](https://github.com/sponsors/rajnandan1)
-[Sponsor Me Using GitHub](https://github.com/sponsors/rajnandan1)
[Buy Me a Coffee](https://www.buymeacoffee.com/rajnandan1)
-[Buy Me a Coffee](https://www.buymeacoffee.com/rajnandan1)
description:A free openAPI spec editor and linter that breaks down your spec into fragments to make editing easier and more intuitive. Visit https://www.frogment.com
tag:"frogment"
image:"/frogment.png"
api:
method:GET
url:https://www.frogment.com
alerts:
DOWN:
failureThreshold:5
successThreshold:2
createIncident:false
description:"Write a description here please"
triggers:
- MyWebhook
- Discord Test
- name:CNAME Lookup
description:Monitor example showing how to lookup CNAME record for a domain. The site www.rajnandan.com is hosted on GitHub Pages.
title:"Kener - Open-Source and Modern looking Node.js Status Page for Effortless Incident Management"
siteName:"Kener.ing"
home:"/"
logo:"/logo.png"
siteURL:"https://kener.ing"
favicon:"/logo96.png"
github:
owner:"rajnandan1"
repo:"kener"
incidentSince:720
metaTags:
description:"Kener: Open-source modern looking Node.js status page tool, designed to make service monitoring and incident handling a breeze. It offers a sleek and user-friendly interface that simplifies tracking service outages and improves how we communicate during incidents. And the best part? Kener integrates seamlessly with GitHub, making incident management a team effort—making it easier for us to track and fix issues together in a collaborative and friendly environment."
keywords:"Node.js status page, Incident management tool, Service monitoring, Service outage tracking, Real-time status updates, GitHub integration for incidents, Open-source status page, Node.js monitoring application, Service reliability, User-friendly incident management, Collaborative incident resolution, Seamless outage communication, Service disruption tracker, Real-time incident alerts, Node.js status reporting"
og:description:"Kener: Open-source Node.js status page tool, designed to make service monitoring and incident handling a breeze. It offers a sleek and user-friendly interface that simplifies tracking service outages and improves how we communicate during incidents. And the best part? Kener integrates seamlessly with GitHub, making incident management a team effort—making it easier for us to track and fix issues together in a collaborative and friendly environment."
og:image:"https://kener.ing/ss.png"
og:title:"Kener - Open-Source and Modern looking Node.js Status Page for Effortless Incident Management"
og:type:"website"
og:site_name:"Kener"
twitter:card:"summary_large_image"
twitter:site:"@_rajnandan_"
twitter:creator:"@_rajnandan_"
twitter:image:"https://kener.ing/ss.png"
twitter:title:"Kener: Open-Source and Modern looking Node.js Status Page for Effortless Incident Management"
twitter:description:"Kener: Open-source Node.js status page tool, designed to make service monitoring and incident handling a breeze. It offers a sleek and user-friendly interface that simplifies tracking service outages and improves how we communicate during incidents. And the best part? Kener integrates seamlessly with GitHub, making incident management a team effort—making it easier for us to track and fix issues together in a collaborative and friendly environment."
nav:
- name:"Documentation"
url:"/docs/home"
- name:"Github"
iconURL:"/github.svg"
url:"https://github.com/rajnandan1/kener"
- name:"Buy me a coffee"
iconURL:"/buymeacoffee.svg"
url:"https://buymeacoffee.com/rajnandan1"
hero:
title:Kener is an Modern Open-Source Status Page System
How the engineering skills should consume this repo's domain documentation when exploring the codebase.
This repo is configured as a **single-context** repo.
## Before exploring, read these
- **`CONTEXT.md`** at the repo root.
- **`docs/adr/`** — read ADRs that touch the area you're about to work in.
If any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The producer skill (`/grill-with-docs`) creates them lazily when terms or decisions actually get resolved.
## File structure
Single-context repo:
```text
/
├── CONTEXT.md
├── docs/adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
```
## Use the glossary's vocabulary
When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `CONTEXT.md`. Don't drift to synonyms the glossary explicitly avoids.
If the concept you need isn't in the glossary yet, that's a signal — either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/grill-with-docs`).
## Flag ADR conflicts
If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
> _Contradicts ADR-0007 (event-sourced orders) — but worth reopening because…_
description:A free openAPI spec editor and linter that breaks down your spec into fragments to make editing easier and more intuitive. Visit https://www.frogment.com
tag:"frogment"
image:"/frogment.png"
api:
method:GET
url:https://www.frogment.com
```
## Sample site.yaml
```yaml
#...
categories:
- name:Hello
description:Say Hello to the world
#...
```
The above will have OkBookmarks and Frogment under home. Earth will be under Hello category.
- Added support for sqlite3 and removed dependency on file system
- Added support for postgres database. Read more [here](/docs/database)
- Added support for alerting. Read more [here](/docs/alerting)
- Added color customization. Read more [here](/docs/customize-site#color)
- Added three new customizations for home page. Read more [here](/docs/customize-site#barstyle)
-`barStyle`
-`barRoundness`
-`summaryStyle`
### Migration
Kener will automatically migrate your data from file system to sqlite3. If you are using a custom domain, you need to update the `site.yaml` file with the new `siteURL` field. Read more [here](/docs/customize-site#siteURL)
Do not forget to add the base path if you are using a subpath. For example, if you are using a subpath `/kener`, then the path should be `/kener/your-custom-js-file.js`.
description: Add database configuration to your kener server.yaml
---
# Database Config
Use the `config/server.yaml` file to configure the database settings.
## Supported Database
- Sqlite (default)
- Postgres
We are adding more database support in the future.
## Sqlite
Sqlite is the default database for Kener. You don't need to do anything to use it. The database file will be created in the `database` folder.
The name of the default database file is `kener.db`. The path will be `database/kener.db`.
You can change the database file name by changing the `database` key in the `server.yaml` file.
```yaml
database:
sqlite:
dbName:awesomeKener.db
```
In this case, the database file will be created in the `database` folder with the name `awesomeKener.db`.
Make sure the `database` folder is writable by the Kener process.
## Postgres
To use Postgres, you need to provide the connection details in the `server.yaml` file.
```yaml
database:
postgres:
host:localhost
port:5432
user:kener
password:kener
database:kener
```
Or if you want to use environment variables, you can do that as well. Make sure the environment variables are set before starting the Kener process. The environment variables should be `PG_HOST`, `PG_PORT`, `PG_USER`, `PG_PASSWORD`, and `PG_DB`.
description: Kener can be deployed in multiple ways. You can use the pre-built docker image or build from source.
---
# Deployment
Kener can be deployed in multiple ways. You can use the pre-built docker image or build from source.
## Prerequisites
Make sure you have the following installed:
- [Node.js](https://nodejs.org/en/download/)
- [npm](https://www.npmjs.com/get-npm)
- Make sure `./database` and `./config` directories are present in the root directory
- [config/site.yaml](/docs/customize-site) Contains information about the site
- [config/monitors.yaml](/docs/monitors) Contains your monitors and their related specifications
- [Set up Environment Variables](/docs/environment-vars). You can use a `.env` file or pass them as arguments. Be sure to add `NODE_ENV=production` for production deployment
You should mount two host directories to persist your configuration and database. [Environmental variables](/docs/environment-vars) can be passed with `-e` An example `docker run` command:
Make sure `./database` and `./config` directories are present in the root directory
Or use **Docker Compose** with the example [docker-compose.yaml](https://raw.githubusercontent.com/rajnandan1/kener/main/docker-compose.yml)
## Using PUID and PGID
If you are
- running on a **linux host** (ie unraid) and
-**not** using [rootless containers with Podman](https://developers.redhat.com/blog/2020/09/25/rootless-containers-with-podman-the-basics#why_podman_)
then you must set the [environmental variables **PUID** and **PGID**.](https://docs.linuxserver.io/general/understanding-puid-and-pgid) in the container in order for it to generate files/folders your normal user can interact it.
Run these commands from your terminal
-`id -u` -- prints UID for **PUID**
-`id -g` -- prints GID for **PGID**
Then add to your docker command like so:
```shell
docker run -d ... -e "PUID=1000" -e "PGID=1000" ... rajnandan1/kener
```
or substitute them in [docker-compose.yml](https://raw.githubusercontent.com/rajnandan1/kener/main/docker-compose.yml)
## Base path
By default kener runs on `/` but you can change it to `/status` or any other path. Read more about it [here](/docs/environment-vars/#kener-base-path)
If you set both API_IP and API_IP_REGEX, API_IP will be given preference
## KENER_BASE_PATH
By default kener runs on `/` but you can change it to `/status` or any other path.
- Important: The base path should _**NOT**_ have a trailing slash and should start with `/`
- Important: This env variable should be present during both build and run time
- If you are using docker you will have to do your own build and set this env variable during `docker build`
```shell
exportKENER_BASE_PATH=/status
```
## Using .env
You can also use a `.env` file to set these variables. Create a `.env` file in the root of the project and add the variables like below
```shell
PORT=4242
GH_TOKEN=your-github-token
API_TOKEN=sometoken
API_IP=
API_IP_REGEX=
KENER_BASE_PATH=/status
```
## Secrets
Kener supports secrets in monitors. Let us say you have a monitor that is API based and you want to keep the API key secret. You can use the `secrets` key in the monitor to keep the API key secret.
```yaml
- name:Example Secret Monitor
description:Monitor to show how to use secrets
tag:"secret"
api:
method:GET
url:https://api.example.com/users
headers:
Authorization:Bearer $CLIENT_SECRET
```
In the above example, the `CLIENT_SECRET` is a secret that you can set in the monitor. To properly make this work you will have to set up environment variables like below
```shell
exportCLIENT_SECRET=your-api-key
```
Remember to set the `CLIENT_SECRET` in your `.env` file if you are using one.
title: Kener - A Sveltekit NodeJS Status Page System
description: Kener is an open-source Node.js status page tool, designed to make service monitoring and incident handling a breeze. It offers a sleek and user-friendly interface that simplifies tracking service outages and improves how we communicate during incidents.
---
# Kener - A Sveltekit NodeJS Status Page System
<p align="center">
<img src="/newbg.png" width="100%" height="auto" class="rounded-lg shadow-lg" alt="kener example illustration">
Kener is status page system built with Sveltekit and NodeJS. It does not try to replace the Datadogs and Atlassian of the world. It tries to help some who wants to come up with a status page that looks nice and minimum overhead, in a modern way.
It comes with all the basic asks for a status page. It is open-source and free to use.
Kener name is derived from the word "Kene" which means "how is it going" in Assamese, then .ing because it was a cheaply available domain.
- Polls HTTP endpoint or Push data to monitor using Rest APIs
- Handles Timezones for visitors
- Categorize Monitors into different Sections
- Cron-based scheduling for monitors. Minimum per minute
- Flexible monitor configuration using YAML
- Construct complex API Polls - Chain, Secrets etc
- Supports a Default Status for Monitors
- Supports base path for hosting in k8s
- Pre-built docker image for easy deployment
### Customization and Branding
- Customizable status page using yaml or code
- Badge generation for status and uptime of Monitors
- Support for custom domains
- Embed Monitor as an iframe or widget
- Light + Dark Theme
- Internationalization support
### Incident Management
- Create Incidents using Github Issues - Rich Text
- Or use APIs to create Incidents
### User Experience and Design
- 100% Accessibility Score
- Easy installation and setup
- User-friendly interface
- Responsive design for various devices
- Auto SEO and Social Media ready
## Technologies used
- [SvelteKit](https://kit.svelte.dev/)
- [shadcn-svelte](https://www.shadcn-svelte.com/)
## Inspired from
Kener draws inspiration from a comprehensive ecosystem of monitoring and status page solutions, reflecting the diverse landscape of network and application performance tools:
Uptime and Status Page Platforms
- Upptime - GitHub-powered uptime monitoring
- Statuspage - Incident communication platform
- Cachet - Open-source status page system
- Upptrends - Global website monitoring
- Hexometer - Website monitoring and performance tracking
description: Kener supports multiple languages. You can add translations to your site.
---
# i18n
You can add translations to your site. By default it is set to `en`. Available translations are present in `/src/lib/locales/` folders in the root directory. You can add more translations by adding a new file in the `/src/lib/locales` folder.
## How to enable a translation
Once you have added a new translation file in the `locales` folder, you can enable it by adding the locale code in the `site.yaml` file.
Let us say you have added a `hi.json` file in the `locales` folder. You can enable it by adding the following to the `site.yaml` file.
```yaml
i18n:
defaultLocale:en
locales:
en:English
hi:हिन्दी
```
> **_defaultLocale:_** The default locale to be used. This will be the language used when a user visits the site for the first time. It is important to note that the default locale json file should be present in the locales folder.
## Variables
There are few variables that you you should not change,
- %hours : This will be replaced by the hours
- %minutes : This will be replaced by the minutes
- %minute : This will be replaced by the minute
- %status : This will be replaced by the status
> **locales:\_** A list of locales that you want to enable. The key is the locale code and the value is the name of the language. The locale code should be the same as the json file name in the locales folder. `en` means `en.json` should be present in the locales folder.
Adding more than one locales will enable a dropdown in the navbar to select the language.
Selected languages are stored in cookies and will be used when the user visits the site again.
There is no auto detection of the language. The user has to manually select the language.
description: Kener gives APIs to push data and create incident.
---
# Kener APIs
Kener also gives APIs to push data and create incident. Before you use kener apis you will have to set an authorization token called `API_TOKEN`. This also has to be set as an environment variable.
```shell
exportAPI_TOKEN=some-token-set-by-you
```
Additonally you can set IP whitelisting by setting another environment token called `API_IP` or `API_IP_REGEX`. If you set both `API_IP` and `API_IP_REGEX`, `API_IP` will be given preference. Read more [here](/docs/environment-vars#api_ip)
description: Monitors are the heart of Kener. This is where you define the monitors you want to show on your site.
---
# Monitors
Inside `config/` folder there is a file called `monitors.yaml`. We will be adding our monitors here. Please note that your yaml must be valid. It is an array.
## Understanding monitors
Each monitor runs at 1 minute interval by default. Monitor runs in below priority order.
-`defaultStatus` Data. Used to set the default status of the monitor
- PING/API/DNS call Data overrides above data(if present)
- Pushed Status Data overrides status Data using [Kener Update Statue API](/docs/kener-apis#update-status---api)
- [Manual Incident](/docs/incident-management) Data overrides Pushed Status Data
## General Attributes
A list of attributes that can be used in all types of monitors.
| name | Required + Unique | This will be shown in the UI to your users. Keep it short and unique |
| description | Optional | This is a breif description for the monitor |
| tag | Required + Unique | This is used to tag incidents created in Github using comments |
| image | Optional | To show a logo before the name |
| cron | Optional | Use a valid cron expression to specify the interval to run the monitors. Defaults to `* * * * *` i.e every minute |
| defaultStatus | Optional | This will be the default status if no other way is specified to check the monitor. can be `UP`/`DOWN`/`DEGRADED` |
| hidden | Optional | If set to `true` will not show the monitor in the UI |
| category | Optional | Use this to group your monitors. Make sure you have defined category in `site.yaml` and use the `name` attribute. More about it [here](/docs/customize-site#categories). |
| dayDegradedMinimumCount | Optional | Default is 1. It means, minimum this number of count for the day to be classified as DEGRADED(Yellow Bar) in 90 day view. Has to be `number` greater than 0 |
| dayDownMinimumCount | Optional | Default is 1. It means, minimum this number of count for the day to be classified as DOWN(Red Bar) in 90 day view. Has to be `number` greater than 0 |
| includeDegradedInDowntime | Optional | By deafault uptime percentage is calculated as (UP+DEGRADED/UP+DEGRADED+DOWN). Setting it as `true` will change the calculation to (UP/UP+DEGRADED+DOWN) |
`dayDegradedMinimumCount` and `dayDownMinimumCount` only works when `summaryStyle` is set as `DAY` in `site.yaml`. More about it [here](/docs/customize-site#summarystyle)
## API Monitor Attributes
A list of attributes that can be used in API monitors.
| api.timeout | Optional | timeout for the api in milliseconds. Default is 10000(10 secs) |
| api.eval | Optional | Evaluator written in JS, to parse HTTP response and calculate uptime and latency |
| api.hideURLForGet | Optional | if the monitor is a GET URL and no headers are specified and the response body content-type is a text/html then kener shows a GET hyperlink in monitor description. To hide that set this as false. Default is `true` |
### Eval
This is a anonymous JS function, by default it looks like this.
> **_NOTE:_** The eval function should always return a json object. The json object can have only status(UP/DOWN/DEGRADED) and lantecy(number)
This page is a showcase of how kener is getting used in the wild. If you want to add your site here, please raise a PR and modify this [file](https://github.com/rajnandan1/kener-docs/blob/main/docs/md/docs/showcase.md)
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.