Flows

A flow is an entry point into a service and everything it runs. Each request to an endpoint, and each message a queue consumer processes, is one run of a flow. Hud groups its data by flow, so you can see how a function behaves inside one endpoint separately from another.

Types of flows

Hud finds endpoints and queue consumers on its own for supported frameworks. For any other entry point, such as a cron job, a script or an unsupported framework, mark the code as a flow with the SDK. You can mark a custom queue consumer as a queue flow, so it shows up under Queues.

What Hud tracks for each flow

• Runs, duration (average, P90 and P100) and error rate.
• Status codes, for HTTP endpoints.
• Every function that ran in the flow, with its own metrics and when it last changed.
• Issues and forensics tied to the flow.

A function that runs in several flows has separate data for each one. On a function's page, you choose which flow to show data from.

When a run counts as failed

Hud marks a run as failed when it throws an exception or, for HTTP, returns a 5xx. With the Bad Request Errors rule turned on, 4xx responses count as failures too. The rule is off by default. A request can also fail without either, such as a declined payment returned as 200 OK. For those, mark the flow as failed in code with the SDK's set-failure call, and Hud treats it like any other failure. The call needs forensics turned on for the service. With forensics off, it records nothing.

You can also attach your own context to the current flow, such as a customer ID or a feature flag, so it shows up in that run's forensics.

Naming custom flows

Give custom flows stable, low-cardinality names, such as cleanup-expired-sessions. Put variable data like user IDs in the flow's context instead of its name. Each SDK accepts up to 1,000 distinct custom flow names per process. Past that, new names aren't tracked. Java and Python log a warning; Node.js doesn't.