Eventarc is a managed Google Cloud service that delivers events from sources to destinations so that applications can react instead of constantly checking.

The simple definition

Eventarc is a fully managed service for building event-driven applications. An event is a small record that says “this thing happened”, such as “a file named photo.jpg was added to this storage bucket”. Eventarc receives events from many places, including Google Cloud services, your own applications and some outside software providers. It then filters those events and delivers the matching ones to a destination, such as a Cloud Run service, a Cloud Run function, a Workflows execution or a web address inside your network. Eventarc delivers events in a standard format called CloudEvents, so every destination sees the same kind of envelope.

The problem it solves

Before event-driven design, applications often relied on polling. A program would wake up every minute and ask, “Is there a new file? Is there a new order? Has anything changed?” Most of the time the answer was no, so the work was wasted, and when the answer was yes, the program might notice it a minute late. Polling also tangles systems together, because the checking program must know where and how to look. Event-driven design flips this around. The thing that changes announces the change, and interested programs listen. Eventarc provides the listening, filtering and delivery so that you do not have to build and operate that plumbing yourself.

Where it is used

Teams use Eventarc to process uploaded images, start data pipelines when new files land, react to infrastructure changes for security automation, update search indexes when records change, send notifications, and connect separate microservices without tight coupling. Because it is managed, there are no brokers to install and no servers to patch.

Before the details of Eventarc, it helps to understand the simple three-part pattern behind every event-driven system.

The three roles

Why this separation is powerful

The producer does not know who is listening, and the consumer does not know who produced the event. This is called loose coupling. You can add a new consumer without changing the producer at all. You can replace a consumer with a better one without telling anyone. If one consumer is slow or broken, the producer is not stuck waiting. This freedom is the main reason teams choose event-driven design for growing systems.

Two styles of working together

Several Google Cloud services seem to overlap with Eventarc. Each has a different main job.

A simple way to choose

A dozen words explain almost everything you will see in the Eventarc console and documentation.

Every event delivered by Eventarc arrives in the same standard shape, which makes consumers simpler to write.

What CloudEvents is

CloudEvents is an open specification, maintained by the Cloud Native Computing Foundation, for describing events in a common way. Before such a standard, every service described its events differently, so consumers needed special code for each source. With a standard envelope, a consumer can read the same basic fields from every event and then look inside the data part for details that depend on the source.

The main attributes

Eventarc can receive events from several kinds of sources, and the choice affects speed, detail and setup.

Direct events versus audit log events

An event is useful only when something handles it. Eventarc supports several kinds of destinations.

How a destination should behave

The classic way to use Eventarc is to create a trigger that connects some events to one destination.

What a trigger holds

A trigger is a small configuration object with a few essential parts. It says which events to accept by describing event filters, which destination to deliver them to, which identity to use when calling the destination, and in which location the trigger lives. Once created, the trigger works continuously with no servers for you to run. Behind the scenes, Eventarc Standard uses Pub/Sub as its transport layer, creating and managing the needed topic and subscription for you.

One destination per trigger

A Standard trigger sends matching events to a single destination. If several services need the same event, you create several triggers, one for each destination, each with its own filter. This is simple and clear, but it can mean many triggers in a large system. The advanced edition, described next, offers a more scalable way to fan out.

The advanced edition adds a central bus so that many sources and many destinations can be connected in a flexible way.

The three building blocks

flowchart LR
  S1["Google Cloud sources"] --> BUS["Message bus"]
  S2["Your own applications"] --> BUS
  BUS --> E1["Enrollment: image uploads"]
  BUS --> E2["Enrollment: security changes"]
  BUS --> E3["Enrollment: order events"]
  E1 --> P1["Pipeline to image service"]
  E2 --> P2["Pipeline to workflow"]
  E3 --> P3["Pipeline to Pub/Sub topic"]
        

What the advanced edition adds

Behind the simple console is a layered design that receives, filters, stores briefly and delivers events.

The big picture

Events are generated by sources and enter the Eventarc system. They are checked against triggers or enrollments to see who is interested. Matching events are handed to a delivery layer, which authenticates to the destination, sends the event and waits for a response. If the destination does not confirm, the delivery layer holds the event and tries again according to its retry rules. The whole path is managed by Google, so scaling, patching and availability are not your concern.

flowchart LR
  A["Event sources"] --> B["Eventarc event intake"]
  B --> C["Filter matching: triggers or enrollments"]
  C --> D["Transport and retry layer"]
  D --> E["Authenticated delivery"]
  E --> F["Destination handles event"]
  F --> G["Success response confirms delivery"]
  F --> H["Error response causes retry"]
  H --> D
        

Follow a single event from the moment it happens to the moment it is handled.

The most important behavior to understand in any event system is what it promises about delivery.

At-least-once delivery

Eventarc aims to deliver each event at least once. This is the usual promise of distributed messaging systems. It means that the event will not be silently dropped while the system is working normally, but it also means that in some situations the same event may be delivered more than once. For example, if the destination processed an event but the confirmation was lost on the way, Eventarc will try again, and the destination will see the event a second time.

An idempotent handler gives the same result whether it runs once or many times for the same event.

Simple techniques

Handling order problems

Because events can arrive out of order, an old event might arrive after a newer one. Use the event time or a version number in the data, and ignore events that are older than what you already have. For example, if the record already shows version seven, an event for version six should be ignored.

Good filters keep consumers focused, reduce cost and avoid accidental loops.

What you can filter on

Filters work on attributes of the event. The most common is the event type, such as an object being finalized in storage. You can also filter on the source or the resource, such as one specific bucket, or on attributes specific to the provider, such as the name of a method in an audit log entry. In some cases you can use patterns, which match many similar values at once, such as all files under a certain folder path. The advanced edition offers a more expressive condition language that can combine several tests.

Avoiding event loops

A classic mistake is a loop. Suppose a function resizes every new image in a bucket and writes the resized image back into the same bucket. That write creates a new event, which triggers the function again, which writes another image, and so on, forever, with a growing bill. Avoid this by writing results to a different bucket or folder, and by filtering so that the function ignores its own outputs.

Sometimes the event as produced is not the shape that the destination wants. The advanced edition can reshape it on the way.

Why transform at all

Different systems expect different layouts. A destination written years ago may want a flat message with only three fields, while the event carries dozens of nested details. Without transformation, you would have to write extra code in every consumer to dig out what it needs. With a transformation step inside the pipeline, the event is reshaped before it is delivered, so the destination receives exactly what it understands. This keeps consumers simple and keeps the knowledge about event shapes in one central place.

Where a trigger or bus lives matters for correctness, speed and compliance.

Matching the source

Many event sources are tied to a location. A storage bucket in one region produces events in that region. For such sources, the trigger usually has to live in a matching location, otherwise no events will reach it. Some sources are global, and for those a global trigger can be used. When in doubt, the documentation for each provider states exactly which location rules apply, and the console will often warn you if the location does not fit.

Destination in a different region

A trigger in one region can often deliver to a destination in another region, but this adds delay and cross-region network traffic, and it can conflict with residency rules. When possible, keep the source, the trigger and the destination in the same region.

An event system touches many services, so careful identity and permission design keeps it safe.

The identity used by a trigger

Every trigger or pipeline works with a service account. This account must be allowed to receive events through Eventarc, and it must be allowed to call the destination. For example, to deliver to a Cloud Run service, the account needs permission to invoke that service. If the destination is a workflow, it needs permission to run workflows. Eventarc then calls the destination with a signed identity token for this account, and the destination can verify that the call is genuine.

Other security habits

Not every destination lives on the public internet. Eventarc can reach services inside your private network.

Delivering inside a virtual network

Many companies run internal services that have no public address. Eventarc can deliver events to such internal web addresses by connecting to your virtual private cloud network through a managed private connection. The traffic stays on Google’s private network and never crosses the public internet. This is important for regulated industries and for services that must not be reachable from outside.

Audit log events let you react to almost any action in Google Cloud, which makes them a favorite tool for security and governance automation.

How they work

Whenever someone or something calls a Google Cloud API, the call can be recorded in an audit log. Eventarc watches for log entries that match your filter and turns them into events. The filter names the service and the method, such as the creation of a firewall rule or a change to an access policy. When a matching entry appears, the event is delivered to your destination, which can then check the change, notify people or fix the problem automatically.

Things to be careful about

The most common first project with Eventarc is reacting to files, so it is worth looking at the flow in detail.

A typical file-processing flow

Useful event types for files

Your own applications can also announce events, turning Eventarc into the backbone of your system.

Why publish your own events

Google Cloud services announce what they do, but only your application knows when an order is placed, a payment is approved or a customer signs up. By publishing these facts as events, you let other parts of the system react without being called directly. The order service simply announces “order placed” and moves on. The inventory service, the email service and the analytics service each listen and do their own work. Later you can add a fraud service without changing the order service at all.

Design events as facts

One event often starts a process with several steps. Workflows is the natural partner for that job.

Why not do everything in one function

Suppose a new file must be checked for viruses, converted, indexed, copied to an archive and announced to the owner. A single function doing all of that becomes long, fragile and hard to retry safely, because a failure in step four forces a repeat of steps one to three. A workflow instead describes the steps, calls each service in turn, waits where needed, retries only the failed step, and records the progress. Eventarc simply starts the workflow when the event arrives.

flowchart TD
  A["File uploaded"] --> B["Eventarc trigger starts workflow"]
  B --> C["Step 1: scan the file"]
  C --> D{"File clean?"}
  D -- "No" --> E["Quarantine and notify security"]
  D -- "Yes" --> F["Step 2: convert the file"]
  F --> G["Step 3: update search index"]
  G --> H["Step 4: archive original"]
  H --> I["Step 5: notify the owner"]
        

Things fail. A good event design decides in advance what happens when they do.

Retries, in simple terms

When a destination responds with an error or does not respond in time, Eventarc retries delivery. The retries use increasing waits between attempts, so a struggling service is not overwhelmed. Retrying continues for a limited period, after which the event is dropped. The exact retry behavior depends on the edition, the destination and settings, so read the current documentation for the details that apply to your setup.

flowchart TD
  A["Event delivered to destination"] --> B{"Success response?"}
  B -- "Yes" --> C["Event marked as delivered"]
  B -- "No" --> D["Wait with increasing delay"]
  D --> E{"Still within retry period?"}
  E -- "Yes" --> A
  E -- "No" --> F["Event expires and may be lost"]
        

Separating temporary from permanent failures

Keeping a record of what failed

Because built-in options for storing failed events can be limited, many teams add their own safety net. The handler writes problem events, with their id and the reason, to a separate store such as a dedicated topic, a table or a bucket, and an operator or a repair job looks at them later. Check the current documentation for any built-in dead-letter features available in your edition, and design your own handling where they are missing.

Event-driven systems are invisible by default. Logs, metrics and traces make them visible.

Three questions to answer at all times

Tools to use

Eventarc scales by itself, but your destinations must be able to keep up.

What decides speed

Handling bursts

Event-driven systems can be very economical, but the costs come from several places.

Pricing depends on the edition and on the type of event, and it can change over time, so always confirm the current figures on the official pricing page. In general, remember that an event system costs money in more than one place.

Ways to keep costs low

Every managed service has limits. Knowing them early prevents unpleasant surprises in production.

Eventarc and its neighbors have limits on things such as the number of triggers or buses per project and location, the size of an event, the rate of events and how long failed deliveries are retried. Exact numbers change over time and differ by edition, so this guide does not list them. Always read the current quotas page, and plan around the kinds of limits that exist.

Teams that build reliable event-driven systems tend to repeat a few simple designs.

These mistakes appear again and again in event-driven systems that become expensive, fragile or confusing.

A short, practical checklist for anyone building with Eventarc.

Best practices

• Choose the right edition. Use standard triggers for simple one-to-one links and consider the advanced edition for shared buses, custom events and fan-out.
• Filter precisely. Accept only the events you need, in the right location and type.
• Assume duplicates and disorder. Write idempotent handlers and tolerate events arriving late or out of order.
• Authenticate everything. Use dedicated service accounts, least privilege and destinations that reject unauthenticated calls.
• Separate inputs from outputs. Never let a handler’s output trigger itself.
• Handle failures deliberately. Retry temporary errors, record permanent ones and alert humans.
• Keep events small. Send identifiers and locations, not large payloads or personal data.
• Document event contracts. Treat event types and fields like public interfaces and evolve them carefully.
• Observe the flow. Log event ids, track volume and delay, and alert on silence.
• Use workflows for multi-step work. Let Eventarc start the process and the workflow coordinate it.
• Manage configuration as code. Keep triggers, buses, enrollments, pipelines and permissions in version control.
• Set budgets and limits. Cap instances and create billing alerts to stop runaway flows early.

Most problems fall into a few families. A calm, ordered check finds them quickly.

An ordered investigation

The same service solves very different problems depending on the kind of organization.

No design is perfect. Knowing the trade-offs helps you pick the right approach for each need.

Standard and Advanced at a glance

Eventarc compared with neighbors

Triggers and buses should be written down, reviewed and applied by a pipeline, not clicked together by hand.

Why it matters more for events

An event-driven system is made of many small rules spread across projects: triggers, filters, permissions, destinations. If these are created by hand, nobody can see the whole picture, and changes happen without review. A missing trigger produces silence instead of an error. Writing the configuration as code makes the picture visible, reviewable and repeatable.

Event systems fail in ways that ordinary tests miss, so they need their own kinds of tests.

Once other teams depend on an event, changing it carelessly breaks them. Treat event types like public interfaces.

Safe changes

Risky changes

Versioning

When a breaking change cannot be avoided, create a new version of the event type with a clear version in its name or schema reference, publish both versions during a migration period and track which consumers still use the old one. Keep a catalog that lists every event type, its owner, its documentation and its known consumers.

You do not need a perfect design on day one. Build in stages, learning as you go.

How to know it is working

Good signs include fewer polling jobs, quick reactions to changes, handlers that survive duplicates, dashboards that show event flow, alerts that catch silent failures early, new consumers added without touching producers, and a clear catalog that any new engineer can read in an hour.

This example is fictional, but it shows how the ideas in this guide fit together in a small real system.

The situation

A small trading company receives about two thousand supplier invoices every day as PDF files, uploaded by suppliers and by an email gateway into a storage bucket. Until now, a script has run every five minutes to look for new files. It is slow, sometimes misses files and occasionally processes the same file twice. The team wants to replace it with an event-driven design.

What you measure shows you early whether your event flows are healthy.

A few wrong beliefs cause many surprises. Clearing them up early saves time.

Each of these myths leads to surprises in production. The cure is the same every time: read the delivery promises, design for repeats and disorder, watch the flow and keep the contracts clear.

A quick reference for the words used in this guide, in alphabetical order.

Pub/Sub is a general messaging and streaming service that carries messages between systems at large scale. Eventarc is an event routing service that receives events from many sources, filters them and delivers them in a standard format to destinations. The standard edition even uses Pub/Sub as transport behind the scenes.

Not guaranteed. Delivery is at least once, so duplicates can happen after retries or lost confirmations. Write idempotent handlers that use the event id or a natural key so that a repeated event causes no harm.

No. Ordering is not guaranteed, especially when retries occur. Use event times or version numbers in the data, and ignore events that are older than the current state of the record.

Common destinations are Cloud Run services, Cloud Run functions, Workflows, services in GKE and internal web endpoints inside your network. With the advanced edition, events can also go to other targets such as a Pub/Sub topic or another bus.

Consider it when you want a shared bus for several teams, when your own applications publish custom events, when one event must reach several destinations, or when you want to reshape events inside the pipeline. For a simple link from one source to one service, the standard edition is usually enough.

Common causes are a location that does not match the source, filters that do not match the real event type or resource, missing permissions, required logs or APIs not enabled, or the source not producing the event at all. Check each step from source to destination in order.

Pause or delete the trigger first to stop the flow. Then fix the design: write outputs to a different bucket or folder, filter so that the handler ignores its own outputs and set limits on instances and budgets as a safety net.

Return an error for temporary problems so that delivery is retried. For permanent problems, such as malformed data, record the event and the reason in a separate store, alert a human and return success so that it is not retried pointlessly.

It integrates with IAM and uses signed identity tokens for delivery, but you must configure it well. Use dedicated service accounts with minimal roles, require authentication on destinations, keep sensitive data out of event payloads and audit changes to triggers and buses.

Pricing depends on the edition and event type and can change, so check the official page. Remember the whole chain: events, transport, audit logging, destination compute, storage and network. Filters, loop prevention and budget alerts keep the total under control.

Yes, with the advanced edition your applications can publish custom events to a message bus. Define clear event contracts, name events as facts in the past tense, keep payloads small and let consumers subscribe through enrollments.

Use a direct handler for one short action that is easy to retry. Use a workflow when there are several ordered steps, branching, waiting or the need for clear progress records and partial retries. Eventarc can start either one.

Eventarc is Google Cloud’s managed service for building event-driven systems. It receives events from Google Cloud services, audit logs, Pub/Sub, partners and your own applications, filters them, and delivers them in the standard CloudEvents format to destinations such as Cloud Run, functions, Workflows, GKE services and private endpoints. The standard edition connects events to destinations with triggers. The advanced edition adds buses, enrollments and pipelines for fan-out, custom events and reshaping. Delivery is at least once and unordered, so reliable systems use idempotent handlers, careful error handling, precise filters, strong identity, loop protection, observability and clear event contracts.

Remember the dispatch center from the beginning: the dispatcher does not fix the fire. The dispatcher notices each call, reads it, applies a rule and sends the right responder. Your job is to write good rules, train good responders and watch the board.

A short self-check for your own system

Ask yourself a few questions. Can every handler safely run twice for the same event? Do outputs ever land where they could retrigger their own handler? Are destinations closed to unauthenticated calls, with a dedicated service account for each trigger? Do you retry only temporary failures and record permanent ones? Would you notice within an hour if a trigger went silent? Is there a catalog that says who produces and who consumes each event type? If any answer is uncertain, begin there.