Run large writes as background jobs

Dynomatic runs large writes as background jobs. A job runs in the app itself, not in the window, so it keeps going when you close the dialog that started it, switch tabs, or reload the window. Each job paces its writes to the table’s capacity. How job pacing works explains the limits it keeps to.

What starts a job

You do not start a job directly. These operations hand their writes to one:

Operation	Runs as a job when	Label in the panel
Commit pending changes from the diff chip or the Pending Changes sheet	100 or more changes are pending, Commit as one transaction is clear, and you are on the Pro plan	Commit N pending changes
Bulk edit with All matching the filter, then Apply to N rows	Always	Bulk edit N matching rows, or Bulk edit rows matching the filter
Import from File or editor	The import has 100 rows or more, unless it merges a row with too many attributes for one update	Import N rows into <table>
Import from a DynamoDB JSON file or an S3 export into the table	Always	Import <source> into <table>
Import from an S3 export into a new table	Always. The job follows DynamoDB’s own import until it finishes	Import <table> from S3
Start backfill on an embedding recipe	Always	Embed <attribute> on <table>
Start embedding in the Create vector index dialog	Always	Create vector index <name> on <table>

An import that has to embed rows without vectors starts an Embed <attribute> on <table> job after it finishes. See Import and Embeddings.

A commit job holds only the changes to existing keys. An edit to a key attribute commits on its own as one transaction, and the toast says how many did. When a commit job ends, the grid runs its query again.

Exports do not run as background jobs. They show in the Transfers panel instead, including an export an agent starts with export_start.

Open the Background jobs panel

The status bar shows a jobs pill beside Transfers once any job exists. It reads N jobs running while a job is working, and N jobs when all of them have stopped. A warning icon appears on the pill when a job needs you, because it paused for a reason other than you, was interrupted, failed, or completed with failures.

Click the pill to open Background jobs. It lists every job, newest first. Each row shows:

• The job’s label, and its kind, table, and workspace.
• A progress bar and done of total. When the total is not known yet, the row reads N so far.
• The failed count, when some rows failed.
• While the job runs, its rate in items per second, the write rate against the job’s ceiling as N of M WCU/s, and About <time> left.
• The state, with the reason for a pause, a failure, or the current step. For example, Paused: by you or Running: waiting for the vector index to become active.

The buttons on a row change with the job’s state.

Pause, resume, or cancel a job

• To pause a running job, click Pause. The row reads Pausing: by you while the requests in flight finish, then Paused: by you. Resume stays unavailable until the job has paused.
• To continue a paused or interrupted job, click Resume. The job continues from where it stopped.
• To stop a job for good, click Cancel. The row reads Cancelling, then Cancelled. Rows the job already wrote stay written. There is no rollback.

A job also pauses on its own when its credentials expire, when access is denied, or when too many writes fail. The row names the reason, for example Paused: credentials expired. Fix the cause, then click Resume. Before a job resumes, Dynomatic checks that its workspace, its table, and the table’s keys are the ones it started with. If one of them changed, the job stays where it was and a message says why.

An import into a new table has no Cancel, because DynamoDB runs that import and cannot cancel it. When it is paused or interrupted, for example after a quit, the row offers Resume and Stop following. Stop following removes the row, and the import keeps running in AWS.

Handle failed rows

To see which rows failed, click View failures. The Failures dialog lists each failed key with its error and the number of attempts, 50 at a time. Click Load more for the next page.

To write the failed rows again, click Retry failed. It appears on a commit, bulk edit, or File or editor import job that failed or completed with failures. An embedding job that failed offers Retry, which continues from where the job stopped. An import from a DynamoDB JSON file or an S3 export offers no retry. Run the import again instead.

Put a commit’s unwritten rows back in the grid

A commit job that stopped with rows it did not write can return them to the grid as pending changes. This includes rows that failed, and after a cancel or a failure, rows the job never reached.

To restage the rows, click Restage on the job’s row, or Restage unwritten rows in the Failures dialog. The rows go back to the table’s tab, or the table opens in a new tab. A toast confirms with <n> changes are pending again in <table>. The job stays in the list until you dismiss it. The row then reads Restaged into <tab>.

After a restage, Retry failed is gone from that job for good, because the rows are yours to commit now. Restage refuses when the job’s workspace now uses another profile or region than the job started with.

Dismiss a job

To remove a stopped job from the list, click Dismiss. When the pill’s last job goes, the pill goes too.

A commit job can hold rows it never wrote and that you never restaged. Those rows exist only in the job, so Dismiss asks Discard the unwritten rows? first. Click Keep the job to keep them, or Discard and dismiss to remove them with the job.

Quit while a job runs

When you quit with a job running, the Pick up where you left off? prompt also says how many jobs will pause, for example 1 background job will pause. After you confirm, Dynomatic pauses each running job and then quits, within about 11 seconds.

The next time you open Dynomatic, those jobs read Paused: the app quit. No job resumes on its own. Click Resume on each job you want to continue. A job that did not pause in time, or that was running when the app stopped without warning, reads Interrupted and resumes the same way.

Find a finished job in Command history

When a job stops, whether it completed, failed, or was cancelled, it adds one entry to Command history. The entry carries the job’s label, the number of items it wrote, and the write capacity it consumed, which the capacity strip counts as writes. Retrying a job updates its entry instead of adding another. An import into a new table adds no entry, because DynamoDB writes that table, not Dynomatic.

Command history requires the Pro plan.

Control jobs from an MCP agent

An agent connected through the MCP server can list, start, pause, resume, cancel, and dismiss jobs with invoke_command, under the same permissions as its other calls. It cannot resume or retry an embedding job, restage a job’s rows, or discard them. It also cannot dismiss a job that still holds unwritten rows.