All four platforms available
Talk to usSee a governed action

Service status

Service status.

This page shows the current service status of elan1 Govern, Work, Decide and Run. Any incident is described in plain words, with what is affected and what to do. If something is not working and this page does not show it, write to elango@elan1.ai.

elan1 Govern, Work, Decide and Run are available. This page lists each service, what it reports, and how we tell you when something goes wrong.

All services operational

elan1 Govern, Work, Decide and Run are available. No incident is open.

6 of 6 components in service0 open incidentsMaintained by hand; an incident is posted here first.

01Components

Six components, each reported on its own.

Each product layer is listed on its own, so its status is never averaged with another's. Status is written out; the square only repeats the word.

Components and their status
ComponentWhat it coversStatusReporting
elan1 GovernThe governed write path: KernelPort, the Right Path, named approvals, the single writer and the proof record.OperationalReporting now
elan1 WorkGoverned agents for the books: ERPNext hosted by elan1 (Mode A) or your own, attached (Mode B), the CA console and approvals.OperationalReporting now
elan1 DecideDecision Studio, Router, Calibration Lab, Review Console, Decision Ledger and Decision Packs.OperationalReporting now
elan1 RunAI infrastructure under contract: the fusion.*/v1 contracts, conformance, substitution, operate and runtime controls.OperationalReporting now
elan1.ai websiteThis site: pages, the governed-action walkthrough, specimens, search and forms.If you can read this page, the website is serving it.OperationalReporting now
DocsReference documentation on a separate docs host: schemas, error codes and SDK guides.The docs summary at /docs is part of the website.OperationalReporting now

Status words used on this page

  • OperationalServing normally.In use today
  • Degraded performanceWorking, but slower than its service level, or failing on a small share of requests.Used when posted
  • Partial outageUnavailable for some customers or for some functions, while the rest keeps working.Used when posted
  • Major outageUnavailable for most or all customers.Used when posted
  • Under maintenanceScheduled work, announced on this page before it starts.Used when posted

02Measures

What each component reports.

Measures, not targets. Service levels are set in each customer’s agreement, so no number on this page is a promise.

elan1 Govern

Reporting now
  • AvailabilityWhether KernelPort answers: a write intent sent to assert gets a decision back, and verify can read the chain.
  • Allow-path latencyTime from a write intent arriving to its gate decision: commit, typed refusal or hold. The time a held write waits for a person is excluded and reported separately.
  • Proof-record write lagTime from a gate decision to its sealed proof record in the chain, so you can see whether evidence is keeping up with decisions.
  • Anchoring lagFrom L2Time from a record being sealed to its Merkle root being anchored with two RFC 3161 timestamp authorities. L2 anchors within 15 minutes.

elan1 Work

Reporting now
  • AvailabilityWhether the Work console loads and agents can submit changes for review.
  • Hosted ERPNextWhether ERPNext hosted by elan1 (Mode A) is serving. An ERPNext you run yourself (Mode B) is reported by you, not here.
  • Approval deliveryTime for a held change to reach its named approver on each approval channel.
  • Write pathEvery change goes through elan1 Govern, so Govern's allow-path latency and proof-record write lag apply to Work as well.

elan1 Decide

Reporting now
  • AvailabilityWhether the Router accepts cases and the Decide console loads.
  • Routing latencyTime from a case arriving to the Router's choice: an answer it may give, or a person.
  • Review deliveryTime for an unsure case to reach the Review Console with the reason it was routed there.
  • Governed actionsAny record change goes through elan1 Govern, so Govern's measures apply to every governed action.

elan1 Run

Reporting now
  • Availability by contractEach contract reported on its own (for example gateway, inference, trace), with the component bound behind it.
  • Gateway latencyTime added in front of every call by routing, the budget hard-stop and attribution.
  • ConformanceThe latest nightly conformance result for each contract, pass or fail, with the run it came from.
  • Scheduled changesUpgrades and substitutions on the upgrade train, shown here with ten working days' notice.

elan1.ai website

Reporting now
  • AvailabilityWhether elan1.ai serves pages. Forms that fail say so beside the button and save nothing.

Docs

Reporting now
  • AvailabilityWhether the docs host serves pages and search.
Why these measures. The allow path and the proof record are what elan1 is for. A status page that showed only “up” would hide the two questions that matter: are decisions being made on time, and is the evidence keeping up with them?
Where the detail lives. How each measure is sampled and the reporting interval are listed in the docs. Anchoring lag applies to records from L2 Attested.

03Failing closed

An outage stops writes. It never waves them through.

The write path fails closed. That changes what an incident means here, so it is worth knowing before you need it.

If elan1 Govern fails

Allows stop.

No model sits in the allow path, and nothing else can grant an allow. Until Govern is back, no write receives one.

If the runtime fails

Writes stop.

The single writer holds a 10-minute, single-use credential. When the runtime under it fails, nothing writes to your system of record until it recovers.

Depends on the mode

Mode A and Mode B differ.

Mode A · Enforced

Govern holds the only write credential, so no write reaches your system of record during a Govern outage.

Mode B · Attested advisory

Over MCP or HTTP, elan1 evaluates and records. What your system does when it cannot reach elan1 is set in your integration.

From the write path on Security.

04Incident history

Every incident, listed and kept.

Incidents are listed here newest first, and stay listed. An entry is never deleted; a correction is added beneath it, with its time.

All time

No incidents posted.

When an incident is posted, it appears here with every update, in order. Minor problems with the website itself are fixed as they are found and are not listed as incidents.

How an incident moves

  1. InvestigatingWe know something is wrong and are finding out what. The first update names the component and the impact we can see.
  2. IdentifiedWe know the cause, or the part of the system it sits in, and say what we are doing about it.
  3. MonitoringA fix is in place. We watch it before calling the incident over.
  4. ResolvedService is back to normal. The entry stays listed with its full history.
  5. Review publishedFor a major outage, or any incident on the write path or the proof record: what happened, what the records show and what changes.

Every entry contains

An incident entry is written for the person who has to explain it to someone else: their auditor, their board or their customer. So it says what happened in words, and what it means for the records.

  • The component affected, and which part of it.
  • Start time and, once known, end time, in India Standard Time.
  • The impact in words: what you could not do, and what kept working.
  • Every update, in order, each with its time. Updates are added, never edited away.
  • For anything on the write path: whether any write passed, waited or was refused, and whether any proof record is affected.
  • A link to the written review, once it is published.

05How incidents are communicated

This page first. Then you, directly.

An incident is posted here before anywhere else, and every update follows in order until it is resolved.

How incidents are communicated
ChannelWhat you getWhen
This pageThe first update and every update after it, in order.First, before any other channel.
Direct noticeAn email to the contacts named in your agreement, for incidents that affect your tenant.On the timings set in your agreement.
Where the law sets a clockReportable cyber security incidents to CERT-In; a personal data breach to the Data Protection Board of India and each affected person.Within the time the law sets, including CERT-In's six-hour window.
Written reviewCause, impact, the records affected and what changes, published on this page.After every major outage, and after any incident on the write path or the proof record.

If an incident touches the proof record

The written review names the range of records affected and how to check them. At L1 the chain is tamper-evident to you: recompute each record’s digest and compare it with the next record’s prev_digest. You do not need to take our word for it. How to verify a record.

Scheduled maintenance

Scheduled work is announced on this page before it starts, with the components and the window affected. elan1 Run’s scheduled changes ride an upgrade train with ten working days’ notice. The notice periods for other components are set in your agreement.

Incident notification timings are set in your agreement. To report a vulnerability, write to elango@elan1.ai and see responsible disclosure. How we handle a personal data breach is in the privacy notice.

Read next

Where status comes from.

Security, residency and data handlingWhere elan1 runs, the write credential, and our role under the DPDP Act.What's nextFuture improvements, in order. No dates.
Verify a proof recordCheck the chain yourself, without asking us.What we claim, and what we don'tEvery claim with its level, mode and status.

// STATUS

A question about a service?

Write to elango@elan1.ai. A person answers within 2 working days.

Talk to usSee what's nextRead the security page
elan1 · Trust & evidence · Status · Last reviewed 6 Oct 2026All four platforms available. Prices exclusive of GST.