Skip to content

GitAegis Cloud

Service status

This page covers GitAegis Cloud. Your local repositories are not on it.

The cloud service is deployed for testing rather than for public use, and no independent monitor is checking it. This page will print a live state only when a real status source produces one.

Deployed for testing · No service level agreement · No uptime figure without an independent monitor

Local Git does not depend on any of this

If every component below were down, GitAegis on your machine still opens repositories, runs operations, takes recovery capsules, restores from them, and runs Doctor.

The desktop application makes no network call to decide whether you are allowed to commit. A licence check that cannot complete lets the app run rather than blocking it. Scheduled account/update traffic fails without blocking local Git. An AI commit report or provider API read happens only after the user enables that optional capability; a failure is visible and changes nothing. None is in the path of any Git operation.

A cloud incident can pause cloud-backed account, AI and browser-authorized provider reads. It does not cost you local Git, local recovery, or your work.

Live status

Per-component state, from a monitor. When there is one.

No monitored source is connected to this page.

Nothing is reporting
  • APINot monitored
  • AuthenticationNot monitored
  • Capsule storageNot monitored
  • SyncNot monitored
  • WebhooksNot monitored
  • NotificationsNot monitored
  • UpdatesNot monitored
  • Website and downloadsNot monitored

These components are not running, and nothing is checking them. This page will report a state when a monitor produces one, and will report nothing until then.

This page will never tell you everything is fine. A page rendered ahead of time cannot know that, and the moment it matters most is the moment it would be wrong.

What this page will report on

Eight components, and precisely what a failure of each one costs you. Read the third column as the useful one: it is the difference between an inconvenience and a problem.

The GitAegis Cloud components this page covers, what each is responsible for, and what a failure of it costs you.
ComponentWhat it coversWhat a failure costs you
APIThe configured account gateway used by optional account-backed actions.Cloud actions fail. Every local operation, capsule and restore is unaffected.
AuthenticationSign-in, session refresh and device binding.New sign-ins fail. The desktop app never asks permission to commit, so local work continues either way.
Capsule storageUpload, download and restore of cloud-backed capsules.Capsules are still taken and written to your disk, and restoring from a local capsule is unaffected. Cloud copies are unreachable.
SyncWorkspace, change set and organisation policy distribution.The last policy distributed to a device stays in force on it. Local Git is unaffected.
WebhooksInbound events from GitHub.Provider state shown in the app goes stale until the component recovers.
NotificationsDelivery of account and workspace notifications.Nothing is delivered while it is down.
UpdatesThe release channel and update delivery.The installed version keeps running. A failed update check is retried later and never blocks anything, and nothing installs without you pressing Restart to update.
Website and downloadsgitaegis.com and the artifact host.Installers are unavailable. Installed applications are unaffected.

None of these components is running today, and none is being checked. Multi-region checks and a degraded-before-down rule are how this page should work; neither is configured, and this page says so rather than describing them as though they were.

Why there is no uptime number on this page

The obvious thing to put here would be a percentage. It is missing on purpose.

An availability target is a claim about what a monitor observed. There is no monitor, so there is no observation, so a target printed here would be a number typed into a marketing page, which is the kind of evidence this product exists to argue against.

The same applies to durability. Cloud capsule storage would have a redundancy story, a set of regions, and a restore exercised on a schedule. None of that is arranged, so none of it is described, and no provider is named.

There is no contractual service level agreement either, on any plan. When availability is measured, the figures will come from the monitor and be linked to their source.

How an incident would be communicated

The commitments, stated now so they can be held to later.

  1. Posted when it is detected, not when it is understood.

    An incident is opened with the components affected and what is known at the time. Waiting for a diagnosis before acknowledging that something is wrong is how a status page loses its readers.
  2. Updated while it runs.

    Updates while an incident is open, including the ones that say “still investigating, no change”. Silence during an outage is its own failure.
  3. Severity is named.

    Degraded: working but slow or partially failing. Partial outage: one component unavailable. Major outage: the API or authentication unavailable.
  4. Closed with a summary.

    What happened and what was affected. Significant incidents get a written postmortem with a timeline, the contributing causes, and the corrective actions.
  5. Security incidents follow a different path.

    An incident touching the confidentiality or integrity of your data is notified to affected people within 72 hours of confirmation, by email, in addition to anything posted here. The handling is described on the security page.
  6. Nothing is quietly deleted.

    Incident history stays published. An incident that turned out to be a monitoring fault rather than a service fault is corrected in place with a note, not removed.

Telling us something is wrong

There is no subscribe button on this page yet, because there is no status host to subscribe to and nothing that would send you anything. Until there is, these reach a person.

Something is broken

support@gitaegis.com, with what you were doing, the time, and the version you are running.

Something is a vulnerability

security@gitaegis.com: reported under the disclosure terms on the security page.

Something changed in a release

The changelog carries every release, including withdrawals and the reason for them.

Something needs an answer

The support page collects the questions that come up most, and where each answer comes from.

Support and troubleshooting

Status questions

30-day trial · No card required

A recovery capsule before every risky Git operation.

You see the exact commands before they run, and the operation is refused if the capsule cannot be written.

Requires Git 2.38.0 or newer, already installed.

Every risky operation, in this order

  1. Previewthe exact commands, shown before anything runs
  2. Capsulerefs, index, staged and working changes, untracked files, operation state: written to disk first
  3. Executethe commands as shown, or not at all
  4. Journalplan, commands, capsule id, outcome
No capsule, no operation. Restore plans, previews, and takes its own capsule.