Every tawa deploy automatically registers an uptime monitor via iec-pulse. No configuration needed — the builder reads your service URL and health endpoint from catalog-info.yaml, and attaches your org (from spec.owner) so the monitor is scoped to you.
The builder includes your owning org slug in the registration payload (org, derived from spec.owner). iec-pulse stores it on the monitor so per-org status pages can show only your services. Older builders that don't send org still work — a missing org never overwrites a known one.
| Check | Interval | Target |
|---|---|---|
| Health endpoint | 30s (prod) / 60s (sandbox) | https://{service}.tawa.pro{healthEndpoint} |
| Custom domains | 60s | Each domain from tawa domain add |
Your service must expose a health endpoint that returns 2xx. The default path depends on your framework:
| Framework | Default | Override |
|---|---|---|
| express / fastify / hono | /health | insureco.io/health-endpoint annotation |
| nextjs | /api/health | insureco.io/health-endpoint annotation |
Every tawa deploy also publishes a changelog for your service. It appears on your status page under What's new — no wiring, no extra command. The source is picked automatically, so even a vibe-coder who never writes release notes gets one:
| Source (in priority order) | What you do |
|---|---|
CHANGELOG.md in your repo root | Keep a CHANGELOG.md (Keep-a-Changelog style — ## headings + - bullets render cleanly). Best control. |
| Fallback: your git commits | Nothing. The builder derives a summary from git log since your last deploy. Write decent commit subjects (feat: …, fix: …) and they become your changelog for free. |
tawa deploy
└─ builder derives notes (CHANGELOG.md → else git log since last deploy)
└─ POST koko /api/plugins/{service}/changelog (stored once per service, upserted)
└─ iec-pulse status page reads it → renders "What's new"
Koko is the single store — iec-pulse reads it live at GET /api/plugins/{service}/changelog (public). Nothing is duplicated. If Koko is unreachable, the status page simply omits the section; deploys are never blocked.
If the service declares spec.walkthrough, the builder re-publishes the changelog after the deploy-gated tests pass with the bundle's walkthroughUrl, so the same Koko record carries the latest walkthrough for the status page to link from What's new (walkthroughUpdatedAt says how fresh that link is; a deploy that produces no walkthrough leaves the previous link in place).
A redeploy of the same commit with no CHANGELOG.md (a config change, a re-roll) derives no new notes, so nothing is re-published — but its walkthrough is still new. The builder attaches just the link to the changelog Koko already holds (PATCH /api/plugins/{service}/changelog), leaving the notes and their publish time unchanged; the build log says Changelog: walkthrough link published (changelog unchanged). Only a service with no changelog in Koko at all gets [warn] … Koko holds none to attach it to.
Tips
`code`). Raw HTML is escaped.CHANGELOG.md.CHANGELOG.md/manifest carries one) and the deploy time.| URL | What |
|---|---|
https://status.insureco.io | Public status page, no login. https://status.tawa.pro is the same page |
https://iec-pulse.tawa.pro/dashboard | Owner dashboard for your org's monitors (Bio-ID login) |
GET https://iec-pulse.tawa.pro/api/pulse/status | JSON status API |
iec-pulse is the whole system: it stores the monitors, runs the checks and serves the pages.
Correction (2026-10-01): this page listed
https://checkcle.insureco.ioas the admin dashboard. CheckCle was the first version of platform monitoring and has been retired (insureco/iec-pulse#58). That address no longer exists, andstatus.insureco.io, which used to show CheckCle's login, now shows the public status page.
The builder saves a pulseMonitorId on your service record after registering the monitor. This is automatic — you never interact with it directly.
If IEC_PULSE_URL is not set on the builder, monitor registration is silently skipped. Deploys are never blocked by pulse failures.
For a target the builder does not deploy (a Cloudflare Worker, a third-party API,
a managed database), register it with iec-pulse and mark it unmanaged, so the
hourly reconcile does not prune it for being absent from Koko:
curl -X POST https://iec-pulse.tawa.pro/api/pulse/register \
-H "Authorization: Bearer $PULSE_INTERNAL_KEY" -H 'Content-Type: application/json' \
-d '{ "serviceName": "relay-inbound", "org": "insureco", "namespace": "external",
"environment": "prod", "url": "https://relay-inbound.example.workers.dev",
"healthEndpoint": "/health", "interval": 60, "unmanaged": true }'
This is a platform-operator call: it needs the iec-pulse internal key. Optional
expectStatus and expectBodyContains replace the default "any 2xx is up" rule.
Details are in the iec-pulse README.
Last updated: October 6, 2026