INTASTELLAR SOLUTIONSHelp Center

System status

Automated HTTP checks from Intastellar Help. Machine-readable snapshot: /api/status.json.

How we measure uptime

Short notes so you know what this page represents.

  • Synthetic checks: automated HTTP requests from our hosting provider to each public URL below — not real-user (RUM) monitoring.
  • Schedule: production runs about once per minute (your project’s cron configuration).
  • A check passes when the HTTP status is below 500; timeouts and network errors count as failed.
  • Timelines, incident log, latency trends, and the headline uptime percentage use stored checks from the last 48 hours (UTC), up to 5000 samples per load (MongoDB TTL about 14 days). The headline figure also treats active operator notices and scheduled maintenance (when they apply) like downtime for that run.
  • All times on this page are UTC.

Scheduled maintenance

No in-progress or upcoming maintenance windows are published right now.

Last deploy

Commit

3e3a4f4 · View commit on GitHub

Branch

development

Message

docs: Update README to include badge for minification workflow status

98.6% uptime

We run these checks automatically on a schedule. Over the last 48 hours (UTC), we stored 2797 runs · 2758 count as fully up: every service responded normally in that run, with no active operator notice or scheduled maintenance applying to that moment.

All checks passingUpdated Apr 8, 2026, 3:58 AM UTC (stored, UTC)

  • Intastellar Consents

    https://www.intastellarconsents.com

    Recent checks — last 48 hours (2797 samples)

    Not fully clear (UTC)

    • — Operator notice
    • — Operator notice
    • — Operator notice
    • — Operator notice
    • — Operator notice
    • — Operator notice
    • — Operator notice
    • — Operator notice
    • — Operator notice
    • — Operator notice
    • — Operator notice
    • — Operator notice
    • — Operator notice
    • — Operator notice
    • — Operator notice
    • — Operator notice
    • — Operator notice
    • — Operator notice

    + 4 more…

    Response time (Intastellar Consents)

    Min 17 ms
    Max 562 ms
    Latest 35 ms
    HTTP 20035 ms

  • Consents CDN (uc.js)

    https://consents.cdn.intastellarsolutions.com/uc.js

    Recent checks — last 48 hours (2797 samples)

    Response time (Consents CDN (uc.js))

    Min 17 ms
    Max 591 ms
    Latest 34 ms
    HTTP 20034 ms

  • Intastellar Help — Help Center

    https://help.intastellarsolutions.com/

    Recent checks — last 48 hours (2797 samples)

    Response time (Intastellar Help — Help Center)

    Min 26 ms
    Max 2120 ms
    Latest 42 ms
    HTTP 20042 ms

  • Intastellar Consents — analytics collect (health)

    https://analytics.intastellarsolutions.com/collect?health=1

    Recent checks — last 48 hours (2797 samples)

    Not fully clear (UTC)

    • — Failed check
    • — Failed check
    • — Failed check
    • — Failed check
    • — Failed check
    • — Failed check
    • — Failed check
    • — Failed check
    • — Failed check
    • — Failed check
    • — Failed check
    • — Failed check
    • — Failed check
    • — Failed check
    • — Failed check
    • — Failed check
    • — Failed check

    Response time (Intastellar Consents — analytics collect (health))

    Min 62 ms
    Max 12002 ms
    Latest 74 ms
    HTTP 20074 ms

Operator notices

Updates posted by the team when we communicate an issue or follow-up (separate from automated probe history below).

  • Intastellar Consents (CMP) Dashboard - CORS Errors

    We have noticed some CORS errors with our APIs for Intastellar Consents CMP platform - causing currently blank page on the dashboard. We are working on the situation to fix it as fast as possible. Consent collection is still working & we do not see any problems with these endpoints. Monitors: Intastellar Consents.

    Updates

    • Update · Apr 6, 2026, 7:52 PM UTC · felix.schultz@intastellar.com · Identified → Resolved

      We fixed the issue - some header requests weren´t allowed to connect. Which caused the API´s to be blocked on the request. Everything is resolved & the Intastellar Consents dashboard, is up an running again.

    Monitors: Intastellar Consents

    Posted by felix.schultz@intastellar.com · · Resolved

    Resolved

Incident log

Each row is one cron run where at least one check failed (newest first), within the same rolling window as timelines and uptime. Times are UTC. Messages come from the probe when available; older history rows may only show a generic reason.

  • Degraded

    • Intastellar Consents — analytics collect (health)

      HTTP 500

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

  • Degraded

    • Intastellar Consents — analytics collect (health)

      Timeout

Footnote — hosting and configuration

This page is public. The details below are for teams that deploy Intastellar Help (environment variables, data retention).

Configure targets with STATUS_CHECK_TARGETS_JSON (full replace) or STATUS_CHECK_EXTRA_JSON (append). A check counts as passing when the HTTP status is below 500. The incident log shows stored cron runs where any target failed in that window, including probe error text when saved. Timelines, the incident log, and latency trends use the same rolling store: the last 48 hours (UTC), up to 5000 samples per request (14-day TTL in Mongo). The headline uptime percentage uses the same window: runs count as up only when every target passed and the run time is outside operator notices and maintenance windows that apply (global or to those targets). Tune with STATUS_HISTORY_WINDOW_HOURS and STATUS_HISTORY_MAX_ROWS. Times on this page are UTC. New history rows store per-target latencyMs; older rows still drive up/down segments until they expire.