Documentation / Events

Events

Mark deployments, releases, campaigns, configuration changes, and incidents so they line up against your Azure cost data and answer "what changed?" at a glance.

On this page

Events are point-in-time markers on your cost timeline. When something significant happens in your delivery lifecycle — a deployment lands, a marketing campaign launches, an auto-scale policy is tightened, an incident is opened — record an event for it. Cirrova draws those events on the same charts as your Azure cost data, so the question "what changed when this spike started?" becomes a glance instead of an investigation.

Overview

Each event captures:

  • A title — what happened, in the words of whoever recorded it.
  • A date and time — when it happened.
  • A category — Deployment, Launch, Campaign, Configuration, Incident, or Other.
  • A tenant — which Azure tenant the event relates to.
  • An optional description — free-form context.
  • An optional tag filter — a tag key/value pair that scopes the event to specific resources (see Tag filters & scoping).

Events are visible to every member of the organisation who has access to the tenant. They're created by hand from the UI, or programmatically via the API as part of a CI/CD pipeline.

The Events page

Open Events from the left navigation. The page shows a chronological list of every event recorded in the organisation, with a filter bar across the top:

  • Tenant — narrow to a single Azure tenant. Defaults to All.
  • Category — narrow to one event category.
  • From / To — restrict to a date range.

Above the list, a small chart preview shows daily spend with the filtered events overlaid as markers — useful for confirming the date range you've chosen actually contains anything interesting.

Creating an event

Click Add event in the top right. The dialog (Add event marker) collects:

  • Tenant — the Azure tenant this event relates to. Required.
  • Title — required. Keep it short and recognisable; e.g. "v2.3.0 deployed to production", "Easter campaign launched", "Auto-scale max raised 10 → 25".
  • Date & time — when the event occurred. Required. Defaults to now.
  • Category — see Categories below.
  • Description — optional free text. Useful for build numbers, ticket links, or anything the title couldn't fit.
  • Tag filter — optional. A tag key and value (e.g. Platform = Nextron) that limits where the event surfaces. See Tag filters & scoping.

Click Add event to save. The event becomes visible on cost charts immediately — there's no delay or polling.

Categories

Six categories are available. Each renders with its own colour and icon on charts and in the list, so you can recognise the kind of change at a glance.

  • Deployment — application or service code shipping to an environment. The most common category for engineering teams.
  • Launch — a feature flag flip, a new product or feature going live, an A/B test starting.
  • Campaign — marketing pushes that drive traffic — a paid campaign starting, an email send, a press release going out.
  • Configuration — non-code infrastructure changes: scaling policy edits, SKU changes, retention rule adjustments, network changes.
  • Incident — a production issue or outage. Recording the start and end as events helps explain anomalous cost patterns during the window.
  • Other — anything that doesn't fit cleanly into one of the categories above.

Categories aren't enforced — they're a labelling convention. If your team thinks of "Launch" and "Deployment" as the same thing, pick one and use it consistently. The filter on the Events page works on whatever categories you actually use.

Tag filters & scoping

An event with no tag filter is a universal event: it shows on every cost chart in the tenant, from the Dashboard down to a single resource's detail page.

An event with a tag filter is a scoped event: it shows only on cost charts for resources and resource groups whose tags include the matching key/value pair. On broader views (the Dashboard, the Cost Explorer, subscription-level rollups), scoped and universal events both appear. On a single-resource or single-resource-group view, only events that match that resource appear — universal events are always shown, plus any scoped events whose tag matches.

How events surface on cost charts Universal event (no tag filter) Scoped event Project=Apex Broad view Dashboard, Cost Explorer Both events shown Broad views aggregate across the tenant Tagged resource Carries Project=Apex Both events shown Scoped event matches the resource's tags Untagged resource No matching tag Universal event only Scoped event filtered out — tag does not match

The motivating use is product- or workload-specific changes. If you deploy resources tagged Project=Apex — Nexora Corp's acquired-company migration estate, say — tag the event Project=Apex too and it'll only surface on charts for resources working on that project. Resources from elsewhere in the organisation stay clean.

Tag matching uses the resource's own tags. Resources missing the key (or carrying a different value) don't see the event. This is the same matching used by Tag Collection budgets, so consistent tagging hygiene pays off across both features.

Where events appear

Events render as vertical markers on every cost-time chart Cirrova draws, colour-coded by category:

  • Dashboard — the daily and monthly spend charts. All events for the selected tenant filter appear.
  • Cost Explorer — events overlay any time-series breakdown you build.
  • Subscription, resource group, and resource detail pages — events appear on the cost history chart, filtered by the resource's tags as described in Tag filters & scoping.
  • Anomaly drill-through — when investigating an anomaly on a resource detail page, events on or near the anomaly window are immediately visible. This is often where events earn their keep — confirming or ruling out a deployment as the cause of a cost spike in seconds.

Hovering a marker shows the event's title, date, tenant, and (if set) tag filter, with a link to the Events page.

CI/CD via the API

Recording an event from the UI is fine for one-off changes, but the value compounds when events are created automatically as part of your CI/CD pipeline — every deployment becomes a marker without anyone having to remember.

Events are created via a POST to the Cirrova REST API. You'll need an API key — see API Reference → Authentication to create one — and a tenant ID.

Example: GitHub Actions

Add the following step to your workflow after a successful deployment:

- name: Record deployment in Cirrova
  if: success()
  env:
    CIRROVA_API_KEY: ${{ secrets.CIRROVA_API_KEY }}
  run: |
    curl -s -X POST https://cirrova-dev.azurewebsites.net/api/public/v1/events \
      -H "X-API-Key: $CIRROVA_API_KEY" \
      -H "Content-Type: application/json" \
      -d '{
        "tenancyId": "<your-tenancy-id>",
        "title": "Deployed to production",
        "description": "Build ${{ github.run_number }} — ${{ github.sha }}",
        "category": "Deployment",
        "occurredAt": "${{ github.event.head_commit.timestamp }}"
      }'
Store the API key as a repository or organisation secret — never commit it to source control. Keys can be revoked and rotated at any time from Organisation Settings → API keys.

The same pattern works from Azure DevOps, GitLab CI, Bitbucket Pipelines, Jenkins, or any tool that can make an HTTP request. The full request and response schemas are in the API Reference.

Editing and deleting

Events can be edited or deleted from the row menu (⋮) on the Events page. Edits cover every field — title, date, category, description, and tag filter. Deletes are immediate.

If a deployment was rolled back or an event was logged in error, deleting the event is the right move — it removes the marker from every chart it appeared on. There's no soft-delete or "cancelled" state.

Previous Optimisation Insights Next Budgets